The Scrum framework includes a pattern of five activities that allow a small team to plan, execute, inspect, and adapt the development of a product in a short, recurring cycle. While each of those activities is easy to understand, it’s also easy to pick up some misconceptions that can, at best, distract a team from […]
The Scrum framework includes a pattern of five activities that allow a small team to plan, execute, inspect, and adapt the development of a product in a short, recurring cycle. While each of those activities is easy to understand, it’s also easy to pick up some misconceptions that can, at best, distract a team from high performance. At worst, they can defeat the entire point of using Scrum. In this post I’m going to focus on the sprint review meeting, comparing the way an effective one feels with some of the ways the event is commonly misunderstood.
By the end of the sprint planning meeting, every team member should have a shared understanding of the overall goal for the sprint, the product backlog items to meet that goal, and what ‘done’ means for each of those items. When the team comes back together at the end of the sprint for the sprint review meeting, the goal is to reach a shared understanding of whether the team has met the sprint goal, and whether each of the product backlog items are finished. While the Product Owner officially owns the decision of whether a given item is complete, is an objective choice. If the item’s unique acceptance criteria and the team’s global ‘definition of done’ criteria are met, then there should be universal agreement that item is finished.
It’s far easier to invoke a vision based on something we can experience than it is to imagine a hypothetical combination of items and features. So, often during the sprint review the Product Owner or other stakeholder will be shown a new capability and identify a change they’d like. “Now that I see it, I really think we should make the banner on that page blue instead of red.” So is the ‘create banner’ backlog item done? If we all agreed at the start of the sprint that color should be red then, yes, this backlog item is done. Making it blue is a new backlog item. The team can take that on as soon as the next sprint if the Product Owner decides it is important enough.
By participating in the sprint review, the whole Scrum team gains a shared understanding of what the product is now. For example, say before this sprint that the product could do ten things. During this sprint we built two more. Now, it can do twelve things all together. That is the ground truth of what exists and is functional, as of today. The Scrum term for this is the most recent “product increment.” Other people might benefit from that understanding, too, so sometimes a team invites stakeholders or other teams to their sprint review as listeners. By inspecting the product increment as a group, we produce the transparency required to make choices about future value delivery that are grounded in reality. Without that shared understanding, it’s too easy to get ahead of ourselves and start planning features X, Y, and Z, when we don’t even know if A, B, and C work yet.
And speaking of features X, Y, and Z, it’s really easy for a Sprint Review discussion of, “Is this backlog item done?” to shift into long discussions of, “Yes! And how could we make it even cooler?” It’s not that we don’t want to have the “Where next?” discussions; the problem is that at that point this meeting has stopped being a Sprint Review and drifted into what are really Backlog Refinement conversations. And there may be a bunch of people (other teams or stakeholders, say) that came for the Sprint Review but don’t necessarily need or want to be a part of Backlog Refinement. So instead, a ScrumMaster (or anyone, really) can suggest that we put a pin in the current discussion (we can come back to it in our next Backlog Refinement discussion with the relevant parties), and get back to the Sprint Review conversation.
A question I often get in Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) courses is “who runs the sprint review?” On a healthy Scrum team, the answer is actually nobody. That’s because Scrum teams are self-organized and self-managing groups, and the goals of the sprint review are straightforward. The Product Owner knows what they’ve come to the sprint review to see: the product backlog items the team agree to build during the last sprint. The Developers know what they’re there to show (the product backlog they agreed to build during the last sprint). They should also know which Developer would be best to show a particular thing because they know who built what. So, no particular member of the team needs to direct the group in how to carry out the meeting because everyone knows what’s expected. And they do this every sprint.
A typical sprint review is a very tactical, bare-bones affair. Developers show a completed capability in a context that feels real enough to everyone, not just their own laptop. They show how it meets the acceptance criteria and relevant definition of done standards. And they’re demonstrating to their Product Owner, a fellow team member that they already talk to on a daily basis and who is steeped in the context of their work. So, it’s really just a hands-on demonstration of what works.
But sometimes the sprint review is misunderstood as something more official and higher stakes. If the team is investing significant time during the sprint to prepare for the review, that likely means that we’re taking time away from value delivery and wasting it on staging. If the thought of something unexpected happening during your sprint review fills you with terror, that likely signals that the team is being exposed to undue pressure from their Product Owner, stakeholders, or some or other party. The sprint review should not have the pomp of a public product launch; it’s a rough and ready working discussion that it should be.
Don’t despair. There’s a couple of immediate steps organizations and leaders can take to get out of these anti-patterns and support healthier Scrum practices.
Scrum is often described as easy to learn, but hard to master. That’s absolutely true! Many of the problems discussed here are easy traps to fall into as a new and inexperienced Scrum Master. Getting them more high quality training like an Advanced Certified ScrumMaster (A-CSM) course would be a great way to expand their skillset and compare practices with other people who’ve dealt with the same issues.
Learn more about our A-CSM training.
One of the most valuable services provided by a seasoned Agile coach is mentoring Scrum Masters and creating a path for organizations to grow and develop ‘ScrumMastering’ as a career. Great Agile coaches can model key behaviors and teach core skills without undermining the position of your Scrum Masters and in a way that supports your teams’ ownership of their improvement.
Learn more about our coaching services.
Sometimes these anti-patterns are the result of outside pressure, like when an organization is used to focusing on task status and forces that habit on a Scrum team. Training and nurturing Agile leadership can create an environment where managers and executives understand the best way to support Agile teams and Agile-based value delivery. Certified Agile Leadership training is a great place to start. Plus, individual or cohort-based leadership coaching can help cement the practices and mindsets needed to get the most out of your Agile teams.
The daily Scrum, sometimes referred to as a daily stand-up, is a quick team synch...