Closing the Loop: Questions to Answer in a Review Meeting

I run hot and cold about being very finicky about language.  On one hand, I think it’s helpful to be specific about words and labels to better enable shared understanding, especially with new ideas/behaviours; on the other hand, sometimes it doesn’t matter what labels people slap on events or artifacts as long as people are clear about what’s supposed to happen and the desired outcomes — quibbling about words can create unnecessary friction.

One of the labels that makes me twitch though is when teams have ‘Sprint Demos’ rather than ‘Sprint Reviews’.  I’ve noticed this label goes hand-in-hand with a tendency to use that meeting exclusively to show completed work, which is only one of the agenda items for a review meeting.  While demonstrating working product to team members and stakeholders is a critical element of this meeting, there are other feedback loops related to the work to consider if we want to understand actual progress and refine the product backlog based on what we’ve learned and delivered.

Here are the questions I often use to frame an agenda for a Sprint Review meeting:

  • What was our sprint goal and what product backlog items did we intend to deliver during this sprint?
    • Without this context, it might be hard for people to be clear about whether the work they’re about to see is the work that was expected
  • What items were completed?
    • The demo – show off that finished work!  The Product Owner may demo the delivered work, but this can also be a great opportunity to give team members a chance to shine in public by having them lead demos.
  • In getting work done, what problems with the work did we encounter?
    • What did we learn about the work along the way that will inform our understanding of upcoming work? Update the backlog accordingly.
  • What did we intend to deliver but didn’t complete? What new issues and learnings related to the work emerged?
    • The point of this discussion item is not to blame the team for not delivering everything they forecast; rather, this information can be very important in updating the product backlog because the team has learned about new issues, dependencies or customer needs.  Keep in mind we’re focusing on issues with the work, not the team – considering how the team worked together through the sprint is the subject of the retrospective.
    • Don’t spend a lot of time on this topic, but don’t avoid it.
  • Based on demonstrated progress to date, what are the updates to the overall release plan?
    • The product owner can use this as an opportunity to align expectations about the overall progress of the work (most of the teams I work with are not releasing to production at the end of every sprint, so having a sense of whether we’re still on track is usually a question of great interest)
  • Are there other things we’ve learned during this sprint about how product use or the marketplace have changed that will result in product backlog updates?

One pattern I’ve noticed that has been helpful in having teams have more productive sprint reviews with real feedback is to separate the team review meetings from demos to the larger stakeholder community (which are usually held a little less frequently).  It’s great if you can have one meeting that serves both purposes, but when you have stakeholders who aren’t familiar with iterative and incremental delivery, or are perhaps challenging to manage, having the Product Owner host a separate stakeholder meeting to demonstrate completed features can sometimes make things less stressful for everyone.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s