Scrum | Story changes during Sprint
At the beginning of each Sprint the team commits to a number of Backlog stories which end up being the Sprint Backlog. Once the Sprint starts these stories aren't allowed to change, they are fixed, frozen until the end of the Sprint.
A frozen Sprint Backlog allows the team to focus on delivery instead of having to deal with change. Every change whether it is small or big is by default denied and placed on the Backlog so it can be prioritized and dealt with later. So what is delivered at the end of a Sprint isn't always according to the latests specifications. Short iterations cause these changing specifications to be implemented much sooner than later.
Or at least that is the theory...
In practice it can be up to the team to decide whether or not they can handle the change within the current Sprint iteration, just call it common sense. Some changes are small enough not to impact the Sprint iteration.
But what if business comes to you with big changes, very big changes? The team has committed to 6 stories (2 week Sprint). After 4 days business comes to you and tells you that 2 stories have been analyzed completely wrong (90% wrong), one of these stories the team has already started on. Even worse, if they implement it as-is it will have very negative impact on several upcoming tasks. What do you do?
In theory Scrum says all changes should be denied, we could do that. Practice teaches us to evaluate each change upon their impact. We can quickly conclude that the impact of these changes is a nightmare for the current iteration, so we deny the change, right?
Don't forget that denying them will cause a disaster upon upcoming tasks, what will you do? How sure is the business about these changes, or about the impact? The business has been wrong before, right? But this time they have truly done their research and it will make your life a living nightmare if you don't implement the new changes...
What do you do?
What do you do?
I know what I would do...
A frozen Sprint Backlog allows the team to focus on delivery instead of having to deal with change. Every change whether it is small or big is by default denied and placed on the Backlog so it can be prioritized and dealt with later. So what is delivered at the end of a Sprint isn't always according to the latests specifications. Short iterations cause these changing specifications to be implemented much sooner than later.
Or at least that is the theory...
In practice it can be up to the team to decide whether or not they can handle the change within the current Sprint iteration, just call it common sense. Some changes are small enough not to impact the Sprint iteration.
In theory Scrum says all changes should be denied, we could do that. Practice teaches us to evaluate each change upon their impact. We can quickly conclude that the impact of these changes is a nightmare for the current iteration, so we deny the change, right?
Don't forget that denying them will cause a disaster upon upcoming tasks, what will you do? How sure is the business about these changes, or about the impact? The business has been wrong before, right? But this time they have truly done their research and it will make your life a living nightmare if you don't implement the new changes...
What do you do?
What do you do?
I know what I would do...
posted by Maarten Volders at
7:45 AM
0 Comments:
Post a Comment
<< Home