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:
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:
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:
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:
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:
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:
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.
No Trainings found