Should We Or Shouldn’t We – Accept Requirement Changes Within A Sprint?

In the agile world, it is one of the frequently asked questions – Do we accept changes within a sprint, or not? Many teams often get confused how to handle requirement changes in middle of iteration? If we do, won’t it disrupt our sprint plan that is in progress? And, if we don’t, would we be less of an ‘agile’ team?

The responses from most Scrum practitioners generally fall somewhere between these two extremes:

• We should freeze the scope for the sprint or iteration and treat all changes as a new requirement – a new story.
• As an agile team, we should focus on delivering value to the customer. And if a change to the story means more value (even if it comes during sprint), we should aim to deliver it.

How to handle requirement changes in middle of iteration .So which one is the right approach?

While the second option may sound more agile, the team may have valid reasons for resisting such last minute changes. But, before we decide which approach is better, it may be worthwhile to review the motivations for both these schools of thought to see how an agile team manages requirements.

First, let’s hear from the pro-change Agilists whose rationale is rooted in the following concepts:

• Agile Value – “Responding to change over following a plan”.
• Agile Principle – “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
• A story must be INVEST – where “N” means “Negotiable”.
• The Agile 3 C’s of a story – where one “C” lays strong emphasis on “Conversations” between Product Owner/customer and the team, as against written and frozen documentation.

Most agile teams usually go through training that talks about the above four pro-change Agile concepts. But, many still end up resisting change more than others. The reason may often be some sub-optimal team circumstances that push them towards taking a strong stand against “change within a Sprint.” Here are some real-world examples:

• The team and/or the manager are new to Agile – they still see each requirement change as a disruption to the current course of action.
• It being a fixed cost project, and may be a little behind schedule. The team wants to avoid any attempt to delay the project any further.
• Management is known to use velocity as a key indication of individual and team performance. Hence, any requirement change during the sprint, however small, is looked down upon by the team.
• The PO is too busy to groom stories in a timely manner and often ends up being giving half-baked stories to the team. The team does not want to pay for the PO’s mistakes.
• The PO – being from the customer side – is always keen to slide new requirements into existing stories in order to maximize return on investment.
• The PO is eyeing an upcoming onsite opportunity (USA) and wants to leave no stone unturned to impress the customer. Sliding small changes into the sprint is too easy an opportunity to miss.

So, where does that leave us – change or no change within Sprint? How would an “Ideal Agile Team” respond to change within a sprint?

I feel a mature agile team will try to find a balance between:

1. Agility – Respond to change to maximize the business value delivered
2. Flow – Stick to a plan developed with team consensus to reduce ambiguity and maximize productivity

It needs a balance between stability and flexibility and a fixed duration Sprint balances both. This is the answer of frequently asked question actually – what is the reason behind fixed sprint duration. The fixed duration Sprint balances both stability and flexibility. In this fixed duration sprint, a mature agile team understands that there is nothing wrong with clarifying acceptance criteria during the sprint, or maybe enhance it a little bit if it helps improve the business value of a feature. At times, they might take in bigger changes too, but only as long as they are an exception rather than the rule. Too big and too frequent changes may suggest a weakness in the backlog refinement process.

Below are some important considerations that may help the team to decide if they should welcome change or not:

• The size of the change
  • While taking a small change my enhance Agility, a big change may disrupt the Flow of the sprint.
• The timing of the change
  • Changes early in the sprint may be preferred rather than towards the end
• The source of change – Is it:
  • A requirement that was missed by PO or BA?
  • A change requested by customer after seeing the product?
  • A change requested by PO based on his gut feeling or has he confirmed his understanding with the customer?
• The frequency of change:
  • Are such changes occasional or the customer/PO getting into the habit of giving half-baked requirements and then changing them frequently?
• The type of project – is it a fixed cost project or T&M based?

In the end, accepting a change in the sprint is a negotiation between the PO and the Development Team, with the final authority resting with the latter. Ideally, the team should come up with a consistent policy (agreed by all, but maybe unwritten) regarding dealing with changes during Sprint, and a sample policy might look like this:

Next question is – how to change your Sprint Plan?  A change in the story or adding a story is a change in the Sprint plan. A change will be accepted within the same sprint only if:

• The change has been confirmed with the customer.
• The change aligns well with the value proposition of a story in the sprint
• The change is small – up to X hours.
• The change has been identified at least X (2-3) days before the end of sprint.

For all other changes, new stories must be added to the backlog – to be taken up in the current (if time permits) or a subsequent sprint.

You can also watch the video to see Should We or Shouldn’t We – Accept requirement changes within a Sprint

I hope this blog has sufficiently answered your all queries related to Should We or Shouldn’t We – Accept requirement changes within a Sprint. You may post follow-up questions here on our DISCUSSION FORUM.

You may also want to check our other blogs of Certified Scrum Master® (CSM) Training Virtual and PMI-ACP® Certification Training