Focus on what was done during Sprint Review

The Sprint Review is generally the hardest event to get right. It's where the Scrum Team and their stakeholders meet, thus the event with the largest number of participants. It's also the event in which different people come with a different purpose.

• The Development Team is present to show their work and receive feedback. They're hopefully also there to connect to their stakeholders.
• The Product Owner is also there for the feedback, but also to verify the longer term road-map and the state of the product backlog.
• The Stakeholders often come to see the things they requested. We also ask them to share insights they have gathered during the sprint and to collaborate on the Product Backlog.

One thing I've observed is that the focus is often on What was planned and What is now "Done". I feel this is an anti-pattern.

While progress is important, I feel the focus should be on What is "Done" and What to do next.

What's so bad about: What was planned and What is now "Done"?

A fair question. Is it important what was planned? You could argue it is. Yet, there is nothing to be done about it now. While it was planned, it wasn't "Done" and can't be delivered. While looking into this may provide ways for the Scrum Team to improve, it's not a topic for the Review, but the Retrospective. The purpose of the Review is to look forward, not to look back.

Instead of focusing specifically on what wasn't "Done", let us instead look what that means for the future.

• Looking at the increment and the product backlog, what adaptions do we need to make?
• Are there any obvious impediments the Stakeholders could take away?
• Are there new insights that could change our opinions?

These questions allow us to take a further.

Alternative: What is now "Done" and what to do next?

Instead of presenting a list of what was planned and a list of what was delivered, can we achieve the same result, but focus on the future? Two ways I've found to work well are:

Let's look at the backlog now and a sprint ago

In this option the team shows the backlog as it was at the beginning of the sprint and what it looks like right now.

This setup has a couple of advantages:

1. The focus is on the Product Backlog and on what to do next.
2. The Product Owner will be able to talk about items that were added and removed at the top of the product backlog.
3. The Scrum Team can focus simply on the work that was done when showing the increment.

By contrasting the two backlogs, the focus is changed from planned vs delivered to the differences and the future.

The Bill-Backlog-Hot-100

In this option the Product Owner shows the backlog as if they were presenting the Billboard-Top-100. Highlighting the top, the work that was delivered ant will likely be delivered next. The fastest climbers, the items that have increased in potential or priority. The items that have sunk to the bottom. And the starred items, items that need to be highlighted or warrant additional discussion.

This setup also has a couple of advantages:

1. It highlights the work "Done" at the top of the list.
2. It allows the Product Owner to bring specific items to the attention.

By not showing what was planned, but highlighting the important changes to the product backlog, the focus is changed from planned vs delivered to the changes and their impact on the future.

The impact on not meeting the plan

"What it the team hasn't delivered what the customer needed?" you might ask. Well, that's an interesting question...

• Did the need appear after the Scrum Team planned their sprint?
• Did the Scrum Team forecast the work, but not deliver it?
• Was the work an essential part of the Sprint Goal?
• Is the customer able to put it to use as soon as the work is "Done"?
• Can the Scrum Team deliver that work in the first few days of the next sprint?
• Were there any impediments left unresolved which may have prevented this from happening?

Some of these questions may be raised. And they are valid questions. I'm not suggesting to ignore these questions. I am suggesting not to put them front and center.

Want to know more? Attend one of my upcoming Professional Scrum Product Owner classes!