Should we allow Changes within Sprint?

In the Scrum world, it is one of the frequently asked questions...

Do we accept changes within a sprint, or not? 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:

1. We should freeze the scope for the sprint and treat all changes as a new requirement – a new story.
2. 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 late in the sprint), we should aim to deliver it.

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.

First, let’s hear from the pro-change Agilists whose rationale is rooted in 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 3 C’s of a story – where one “C” lays strong emphasis on “Conversations” between PO/customer and the team, as against written and frozen requirements.

Though most agile teams usually go through a training that talks about the above four pro-change Agile concepts, many still end up resisting change more than others. The reason may often be attributed to some sub-optimal circumstances that push the team towards taking a strong stand against “changes 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.
• The project being fixed cost, and perhaps a little behind schedule, the team wants to avoid any attempt to delay the project any further.
• Management is heavily inclined towards using velocity as a key indication of team performance. Hence, requirement changes during sprint that usually mean extra work are pushed back 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, resulting in lots of rework effort. The team hates to pay for PO’s inefficiency.
• 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 (or team lead) is eyeing an upcoming onsite opportunity (USA) and wants to leave no stone unturned to impress the customer. Sliding extra work into the sprint is too easy an opportunity to miss.

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

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

1.      Better Agility – Respond to change to maximize business value delivered

2.      Smooth Flow – Stick to a plan developed with team consensus to reduce ambiguity and maximize productivity

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 decide if they should welcome change or not:

1. The size of the change

• While taking a small change may enhance Agility, a big change could disrupt the flow of work in the current sprint.

2. The timing of the change

• Changes early in the sprint may be preferred rather than towards the end

3. 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?

4. 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?

5. The type of project – is it a fixed cost project or T&M based?

Ideally, accepting a change in the sprint should be a negotiation between the PO and the Development Team – to be facilitated by the Scrum Master. With time, it may be a good idea to formulate a consistent team policy on how to deal with changes during Sprint, and a sample policy might look something like this:

A change to the story will be accepted within the same sprint only if:

1.      The change has been confirmed with the customer.

2.      The change aligns well with the value proposition of a story in the sprint

3.      The dev team feels confident the change is small enough to be delivered within the sprint:

a.     The change is small – up to X hours.

b.     The change has been proposed X days before the end of sprint

4.      If the change is deemed big enough or disruptive, consider revisiting the sprint scope:

a.     Estimate the change separately (X story points)

b.     Pull out another story of similar size to improve feasibility of delivering the change

The above approach may work for cases where the requirement changes are manageable – say less than 20-25% of sprint scope. In cases where the business model necessitates that team stays open to frequent requirement changes (more than 25%), the team may find them too disruptive – often leading to a stressful environment and low employee morale. It may be worthwhile to consider Kanban Method for such dynamic business scenarios.

Thanks for taking time to read this post. Request you to share your experience on what solution has worked for you in managing requirement changes within the sprint. Cheers!