So the sprintis a Failure!
So the sprintis a Failure!
It’s time for the Sprint Review. In the room, members of Team Titan (Product Owner,Development Team & Scrum Master) & key stakeholders are present. The team is about to demonstrate the work that is “Done” by them in the current sprint. Even though this is the team’s fourth sprint review but they seem to be a little nervous.
So, PO kicked-off the meeting as always by explaining what PBIs have been “Done” and what has not been “Done”. Stakeholders seemed a little flinched by hearing some work has not been done but didn’t say anything for now. Then Development Team continued by demonstrating only the “Done” work together with following,
- Answering any questions about the increment
- Discussing what went well during the Sprint
- How new work emerged as they learned more during the sprint and added it to the
- What problems they ran into, and
- How those problems were solved
Now comes the explanation of the team’s nervousness as someone from the stakeholders said, “So the sprint is a failure!”
Are you familiar with this scenario? Maybe not exactly this same scenario but something similar? Even if not similar, then maybe you might have heard the above statement/question (as sometimes it’s posed as a question than a statement).
I’ve heard this statement, a lot, and maybe this is a very common statement in organizations who are new in adopting Scrum (or doesn’t know about Scrum & it’s empiricism way of working/planning), because they try to equate sprint success or failure with the phases system of predictive life-cycle. They see the team’s forecast of the
sprint as a commitment and assume if all the work selected at sprint planning is not done, then sprint failed. In addition, if new work was identified during the sprint then the team didn’t do sprint planning properly, as they are supposed to identify all the work at the planning.
The simple answer is that there is NO fail/failed sprint in Scrum. I know we need some context in this matter, so here it is.
It is common for teams that they have some unfinished work (i.e. it’s not fulfilling to their DoD) at the end of the sprint, but this doesn’t mean that sprint failed. Even according to Scrum Guide — 2017,
“Sprint Review is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”
The emphasis here is to be transparent about the progress, inspect the progress & based on the inspection’s result adapt your approach. Even if the team didn’t complete any “Done” work, they should come away with some learning/insight to work in a different way (i.e. inspect & adapt).
The only case where we can even say that sprint is a failure is if we didn’t come away with some learning/insight (i.e. we couldn’t inspect & adapt at the end of the sprint), then we can say the sprint has failed.
If you notice here, all the discussion is about being transparent about progress and inspect & adapt, without inspecting & adapting we are not taking any advantage of Scrum & its empiricism. Even if we complete all the work in all of the sprints without inspecting & adapting, there is a very good chance that customer satisfaction or any other reason for adopting Scrum may not have achieved.
I hope the theme is clear that only completing the work is not important but inspecting it & adapting is equally important too.
P.S. Oh and if you are wondering about the above scenario, Scrum Master should train or educate stakeholders in empiricism way of planning (i.e. evidence-based planning).
I hope you’d enjoy this article. Let me know your thoughts in comments, so I can inspect & adapt as well. Keep Agiling On!