Wasting your time in the Scrum theatre. Part III: Sprint Review
Executive summary: Who exactly is reviewing what during a Sprint Review in Scrum?
The Scrum Team and external stakeholders enjoy the Sprint Review together
The Sprint Review – the first of the Boundary Events – is a technical discussion about the team’s accomplishments in light of the Sprint Goal, centered around a demo showcasing these accomplishments to the participating stakeholders external to the team. The single most important purpose of the Review is to assess where the team is and where it is heading considering the bigger context of the work, i.e. the vision of the product/service and its role in achieving the organization’s mission. That’s why it’s key here to trigger external stakeholders – ideally the customers – to share their feedback, ideas, and other input. The demo serves as the key stimulus for a “harvest of insights.”
During the Review, the Delivery Team discusses what went well during the Sprint, what major, unexpected technical challenges occurred, and how these were solved, still from a technical perspective. Also, Sprint Backlog Items that could not be completed based on the clear Definition of Done, shall be discussed and put back into the Product Backlog for re-estimation and re-prioritization, potentially to be pulled for the next Sprint.
When you hear this, be suspicious
“Anything to show to the PO for review?”
The Demo is not for the Product Owner! Even though s/he’s the ultimate decision-maker when it comes to the content, the PO is not the boss of the team! The work should be done for the customer, not for the PO! Many team’s Definition of Done necessitates that the PO reviews the backlog item before it could be marked as Done. Even in this case, the PO review has to happen before, and not during the Sprint Review
“Who wants to show something to the team?”
The Demo is not a team-to-team activity. Without external stakeholders being present at the demo there’s no opportunity for the Scrum Team to harvest insights. Avoid keeping the team in an opinion bubble, otherwise their decisions will fail to benefit the customer. Besides that, if the demo is the first occasion the team sees what’s been Done, collaboration should be improved – to put it mildly
“Let’s show it to these guys so they can show it to the customers”
It’s OK to demo to stakeholders who are external to the team but internal to the organization. Such stakeholders can be e.g. management, sales, or “people on the field.” What’s not OK though, is to artificially separate the Delivery Team from the end customers. The more indirect the team’s connection to the customers is, the bigger the chance that they will deliver stuff according to the agenda of some arbitrary manager. Unfortunately, such agendas rarely match that of the customer
“Does anybody want to show something?”
Do not “surprise” the PO in front of the customers! By the time of the Review, the PO shall already know what was Done, thus what will be shown to the stakeholders at the demo. If it’s OK for the PO to first see the results on the demo, it’s because s/he did not invite any stakeholders – which defeats the whole purpose of the demo anyway
“Can we consider this item Done?”
The Definition of Done should be crystal clear for everyone, so the team members can work toward the same target. Uncertain questions around whether something should be considered Done or not are a clear sign of the lack of common understanding. Time to schedule a session for the near future to straighten things out!
“OK, so this ticket spills over to the next Sprint…”
Do not push not Done items automatically over to the next Sprint! Put them back into the Product Backlog, and re-estimate the remaining work either immediately or during the next Sprint Planning, and make sure that it’s still relevant in light of the other items at the top of the Product Backlog. This way, you make sure that instead of defaulting to past decisions, you deliberately pay attention to value delivery, and consider changes since the last Sprint.
Check out the Sprint Review in our Scrum events cheat sheets
No Comments