Presenting Undone Work
Imagine there are three days left in the sprint, and stakeholder expectations are very high for the increment that the development team is building. Issues have emerged during the sprint that have slowed the development team, but the whole Scrum team has collaborated to keep the sprint goal intact. It’s clear that, although the team will meet the sprint goal, some of the functionality the stakeholders were really excited about won’t be fully tested and integrated into all environments. The development team’s definition of done states that the code must be tested and integrated in order for it to be considered “done.” But given the pressure from stakeholders, the Scrum team decides to include the functionality in the sprint review anyway.
During the sprint review, the team presents the untested/unintegrated work to the stakeholders. Despite the team trying to make it clear that the work isn’t yet ready for production, stakeholders leave the meeting excited to have the functionality. A release happens the following day (as authorized by the product owner) but the untested/unintegrated features aren’t part of it. The team plans to include those features in the next release.
After the release, stakeholders are disappointed because they expected to see more features than they got. They ask the product owner why features they saw the previous day aren’t included. They don’t understand what testing and integration means, but they think it sounds simple enough.
No. When the product increment isn’t done by the end of a sprint, it’s not potentially releasable. In Scrum, an increment is usable, tested, integrated with previous increments, and safe for a customer or stakeholder to use. If the increment isn’t done, you don’t know whether any of these criteria are true. It’s too risky to release undone work because you can’t know the impact (positive or negative) that using the untested product could have. When a development team doesn’t meet the definition of done, they take away the product owner’s ability to release to production.
Presenting undone work in a sprint review leads to ill-informed stakeholders. Stakeholders are often outside of the Scrum bubble and don’t fully comprehend the terminology that Scrum teams use. If, during a sprint review, stakeholders are disappointed by the team’s lack of progress, a great opportunity exists to have a discussion about all the complex factors that affect the Scrum team and explain the issues that the team faced. Many product owners love the sprint review precisely because it gives them a chance to show stakeholders how hard and complicated the Scrum team’s work is.
Scrum teams should always be forthright about where things stand and not try to overstate their progress in order to please others. This is where you, the Scrum master, can really help the Scrum team understand that it’s always better to be honest with stakeholders than to paint a rosy picture that isn’t accurate.
Avoid the temptation to present undone work in a sprint review, or you may set false expectations. Presenting undone work to make it sound like the team has accomplished more than they really have isn’t worth potentially degrading stakeholders’ trust in the team. It’s cliché, but honesty really is the best policy. If the team ran into problems during the sprint, be upfront about it and work with stakeholders to try to remove any impediments.