Sprint Review question
Some background:
We just completed a sprint where the Development Team failed to reach their Sprint Goal. A number of potential causes for this, including an overambitious sprint forecast, poorly-constructed sprint items, significant unknowns that weren't identified until the actual sprint work began, and a lack of honest assessment in their Daily Scrums around progress. Plenty of great material for our Sprint Retrospective discussions!
It should be noted that this is a mature Scrum Team with a solid history of delivery and an excellent relationship with their PO.
The question then is as follows:
The Development Team and the PO desire to discuss and present some of the delivered and "signed off" functionality, even though the completed work isn't directly associated with completed sprint items that meet DoD. Again, a result of a very messy sprint that made progress toward the Sprint Goal, but did not achieve it. The completed work is a thin layer of the desired functionality, and the goal of discussing and presenting it is to engage business and stakeholders and elicit feedback. In hindsight, perhaps the sprint goal and supporting items should have referenced such a thin, initial version.
I'm interested in what others feel regarding this approach. Should there be a hard and fast line around only discussing and presenting items that meet DoD? Should the Development Team have taken time to rework/rewrite sprint backlog items as they discovered the additional scope?
This depends on your perspective. The Scrum Guide section on Review (https://www.scrumguides.org/scrum-guide.html#events-review) states (emphasis added by me as it pertains to my following discussion.
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
- The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
It says that only the "Done" is presented. But personally I never let my teams pass up an opportunity to get stakeholder feedback. I have had similar situations and my team went into the Review being very open about the fact that was about to be seen is only part of the work that they had wanted to do. They explained why they were not able to get as far as they wanted and then asked for feedback on everything that could be presented. Be transparent about the Sprint and take every opportunity to get stakeholder feedback.
As for the Sprint forecast, as soon as the Development Team discovered issues, they should have started to replan even if that meant impacting the entire Sprint. If this team has good relationships all around it should have been a fairly easy conversation. This kind of situation will happen often in varying degrees of complexity. The purpose of all the Scrum Events is to provide cadence to inspect and adapt. The most important and frequent is the Daily Scrum. Use the events for what they are meant and do not be afraid to say "we seem to have overestimated our abilities and underestimated the amount of work." That is success not failure.
Should there be a hard and fast line around only discussing and presenting items that meet DoD?
What would the effect of such a policy be on transparency? How would work “Done” and “not Done” then be explained by a Product Owner and understood?
Should the Development Team have taken time to rework/rewrite sprint backlog items as they discovered the additional scope?
If they did not, what would the impact again be on transparency? How would the work which truly remains become evident?