Ask this Question at the End of Your Sprint Reviews

"Should we pivot, persevere, or publish this?" This is a powerful strategic question that prompts the team/stakeholders to take action from the Sprint Review. Instead of mindlessly completing requirements then demoing them, use the review to funnel feedback directly into subsequent sprints, get the product into customer's hands early, or avoid disaster! We'll discuss in depth further down in this post. Before asking this question, it's important that the review be engaging, and informative. I'll outline why in the first 3 parts before expanding on this question.

What's a Sprint Review?

Sprint Reviews are meeting in Scrum where the team "inspects the outcome of the sprint and determines future adaptations." I see many teams skipping this event; but in my view Sprint Reviews are just as important as any Scrum event. Even if you're not doing Scrum, you should be evaluating your product frequently. After all, why wait until you're "done" to find out if you were headed in the right direction?

The Importance of Effective Sprint Reviews

Most teams skip sprint reviews because they don't see any value in them. Stakeholders don't attend, customers won't see any of the work until months/years later, or they won't change direction after inspecting the product even if that direction is disaster.

Sprint Reviews are effective when the team feeds feedback from the review directly into the next or near future sprints. This means: one, there needs to be feedback, and two, the team has the agency to adapt their work based on that feedback. If these two things aren't present, the review probably isn't effective.

Agility is about adapting and changing based on data and feedback as early/frequently possible. If we are ignoring problems, bad feedback, or opportunities to do better, the product could fail massively; a tragic failure that we saw coming and could easily avoid.

Powerful Practices in Sprint Reviews

Put the product in the customer's hands. Instead of a boring powerpoint, or attendees passively watching a demo, give them the keyboard, controller, or remote. In one team, our sprint review was "Science Fair" style. Stakeholders played with app on different devices, as the developers and product manager wandered the room answering questions and observing. Yes it's scary, and the customer will click on the wrong things and mess up. These are learning opportunities for the team.

Inform attendees that this product won't be perfect. Reviews are not Apple keynote presentations. Developers may dive into consoles, tweak things, or error messages will pop up. This is ok. It's better we see the kinks now than in a live incident in prod.

Collect feedback. Have the attendees put their thoughts on stickies so that the feedback is recorded and can be things to do in the next sprint.

The Power of a Closing Question

Now that we understand what an effective Sprint Review is, imagine we've reached the end of the review. There were great comments and questions; a very engaging session. Typically even in an engaging review, teams thank everyone for attending and ends the meeting. Instead, I recommend asking this:

Shall we Pivot, Persevere, or Publish?

This is a strategic question that prompts us to do something about the outcome of this sprint. Let's break each part of this question down:

• Pivot - This isn't working. We need to change direction, the problem, or the customer.
• Persevere - We are tackling the right problem, but the solution isn't right. We should spend another sprint working on it.
• Publish - We think the solution works; let's release this solution to the masses, or test this out on a wider group of users to validate.

Having this discussion at the end of the sprint (or at any point during the sprint for that matter), breaks us from mindlessly completing requirements and stories. It reinforces the value of releasing small product increments as often as possible. Pivot/Persevere/Publish encourages us to have valuable outcomes at the end of the sprint rather than half finished, half tested work. This question makes the Sprint Review actionable- "based on the feedback, what do we do with what we've built?" Escape the feature death march!

Prompting Action Promotes Measurable Benefits

You can realise the impact of this technique measurably:

• Realised reduction in scope/cost- We built far less than we thought we needed, saving both time and costs. By deciding to Publish the product early, we learned that the customer is happy with what we built and can move on to other things.
• Time to Market- How early we were able to get the product into real customers and thus generate revenue, even in small amounts.
• Release Frequency- How often customers are experiencing an improvement in the product.
• Team Motivation- The impact of team's motivation seeing their work in production immediately after creating said work.
• Feedback Loops- How quickly are we actioning feedback from customers and stakeholders into subsequent sprints or work, reducing the cost of change, rework, or defects.

Conclusion

Have an effective sprint review, then prompt the team and stakeholders to Pivot/Persevere/Publish their work. Get the team/stakeholders to acknowledge that the project isn't working and Pivot direction. Taking in feedback from stakeholders and customers, Persevere by implementing that feedback directly into the next sprint. Most importantly, if we have working, tested software at the end of the sprint, Publish it! Get it in front of real customers to learn if it makes them happy or needs to improvement. Doing this as early as your first sprint, and doing so every sprint, will motivate the team, reduce costs/scope, and delight customers with continuous improvement to the product!