Almost every scrum team has had one of those sprints. You know the ones, where everything is so close to being done, if only we had another few hours… or another day… or…? When this is added to release time pressures it’s even more tempting to keep working on getting things done rather than stopping to review and reflect, but let’s talk about why it’s a bad idea to fudge the end of sprint process.
The Sprint Review
The sprint review is incredibly important for communicating what went wrong and what has actually been delivered. Even if nothing has been delivered, it’s better to be honest about it than to cover it up. Scrum works best when teams and customers collaborate, but no-one can make their best decisions unless they have an honest picture of the current state of the software. It’s also true that broader communication increases the chance that someone with the knowledge to provide a solution to any problems will come forward to help.
If you don’t see skipping the sprint review as a problem then that could be a sign that the attendance and agenda need to be reviewed to get more value out of the event. Look at what the scrum guide says you should be achieving from it and seriously consider whether your experience matches that. The sprint review is a chance to communicate progress, gather feedback, collaborate on future plans and celebrate our achievements. With so much potential value, it’s hard to see how any argument to skip it could hold up under any kind of scrutiny.
Similarly, the sprint retrospective is an opportunity for the team to really examine what went wrong and figure out how to avoid it in the future. If you skip the sprint retrospective, then you increase the chance that you’ll make the same mistake again next sprint.
Dealing with Dysfunction
The fact is that at the beginning of the sprint the team thought the work would be complete by the end of the sprint. Delaying the sprint review and retrospective, or worse, skipping them altogether, merely avoids dealing with and learning from the issues that arose. The team needs to deal with the dysfunction while it’s fresh in their minds and in time to have an impact on the next sprint. This can be the most important when there’s an impending deadline, even though this is the most difficult time to convince yourself, and the organisation, to take time out for learning and to ensure the product changes will actually meet the desired end goal. If we avoid the sprint review, we could just be in denial and avoiding the true state of the project.
Another problem with delaying the sprint review is that rushing to meet the new end of sprint could lead to quality compromises. Sprints should be completed comfortably or not at all. If quality is at risk, it’s important to have the sprint review in order to highlight this and help stakeholders make the right decisions regarding scope vs quality questions.
At the core of things, sprint reviews and retrospectives are about reducing risk early. By inspecting our current progress and how it tracks against the most up to date vision of our goal, we can identify deviations and make appropriate adjustments. Rushing on may feel more productive, but if you don’t stop to take stock of things, you might just be rushing off in the wrong direction.