Change in a story
Let’s say your team work on a project, to build a web services app. During the 3rd sprint, the team will work on a web method, splitted in multiple stories (with X the name of the file returned by the method):
- “As a bank, I want to retrieve a “X” JSON File with correctly formatted customer entry records so that I can process it.”
- “As a bank, I want to retrieve a “X” JSON File with correctly formatted payment entry records so that I can process it.”
- Etc.
You start working, but after one week, the client calls your Scrum master and says: “the format of the customer entry has changed!”. Your team (and yourself) was working on that story … and this negates the work that's being currently done. It may also significantly impact the team's overall deliverables for the sprint.
As I understand a change, I should write another story and put it on the backlog, but in this example the story doesn’t change, but its content does.
What would be the best way to deal with this change?
Thanks in advance,
> Client calls your Scrum master and says:
> “the format of the customer entry has changed!”
The first thing the Scrum Master should do is to inform the Product Owner. The PO can then work with stakeholders to understand this apparent change in requirements, and with the Development Team to understand its impact on the Sprint Goal.
The team may need to revise their plan of work on the Sprint Backlog, so this change can be accommodated and the Sprint Goal can still be met. If the Goal is no longer viable then the PO may consider cancelling the Sprint.
Hi Ian
Thanks for your answer. Based on your feedback, I guess the best way for my example should be to close the sprint: the goal can no longer be met.
Now, let's say your team work on a project, and this kind of change happens frequently in this project. It seems that the stakeholders aren't sure about their needs... but they do want the team to meet the deadline. Would it be best to :
1) Start a new Sprint, taking into account the change, but knowing that an other change may be negating the work done again. (this seems a bit hazardous for the well beeing of the team and the project).
2) put the project in a deep sleep for a short duration, waiting for the stakeholders and the PO to be sure about what they need.
Thanks in advance,
Cancelling the sprint is the last resort, it is also possible the PO can work out a new/adjusted goal for the sprint that will deliver business value and can be met by the development team. This will keep the cadence for the team intact and they will deliver value.
If the Goal is no longer viable then the PO may consider cancelling the Sprint
=> Absolutely true @Ian, the sprint can be cancelled only when its goal is obsolete.
Client calls your Scrum master and says:
“the format of the customer entry has changed!”
=> Indeed, this is the role of PO to deal with stakeholders to assess if this demand is legitimate, and then to assess this change with the Dev Team. Our team used to handle with this situation, and if PO has the final word, this is only after having listened to the Dev Team opinion.
Here are few suggestions I have:
1. SM should contact PO to work with stakeholders.
2. I feel in your scenario, smaller duration sprint may work (and decide Sprint Goal accordingly).
3. Cancelling sprint should be the very last step as it has some negative impacts on the team.
Correct. A shorter duration Sprint will reduce the window of opportunity for the various frictions to take effect, and its goal is more likely to be achieved.
If that doesn't work or is impracticable, it may be that the situation at hand is more chaotic than complex. Scrum is aimed at complex problems where there are significant risks and unknowns, but a Sprint Goal can be framed and can be expected to be stable.