Sprint Review – Make it much more than a demo…

sprint reviewThe Sprint Review, just like the iteration retrospective, is one the most important feedback loops in a Scrum team’s toolbox.

According to “The Scrum Guide,” the purpose of the Sprint Review is to “inspect the increment and adapt the backlog as needed.” Let’s unpack that a bit.

During the review the team and their stakeholders discuss what was worked on during the sprint.  Generally steering clear of boring recaps of technical details, a good review will be a collaborative event, eliciting customer and stakeholder feedback. Some of the work will be potentially shippable, other work will already be live, and some work will not yet complete (gasp) but in a state where feedback can be obtained.

If the team stops there they will have covered only the inspect aspect of things. And the event is “just a demo.” However if they keep going, they gain information that is can used to inform the delivery of value via the upcoming planning and grooming event. That’s the adapt piece.

One of the best ways I’ve come across for making the ceremony much more than a demo is to make sure the team tells a good story.

Tell a Good Story

Start by reiterating what the goal of the sprint was. (The goal was defined during sprint planning, and kept fore front during the entire iteration, right?)  The during the review, maintain a focus on what’s in it for the customer.

Assuming the team is using personas, go as far as “bringing the end user” into the review. Demonstrate a feature using the persona’s name, profession, their context, their concerns.

A successful story line, one that focuses on value and strategy, one that elicits feedback as well lays the ground work for “what’s next” might look like this:

  • “Here’s what we did and why.” Include one of the following statements:
    • “This benefits our customer (insert persona;s name here) in the following ways: ____________________.”
    • “Our customer’s (insert persona’s name here) experience of this will be _____________.”
  • “Here’s how we approached it and the results… showing the functionality from the customer’s perspective (again, not from the code level…)
  • Trailers for what “coming soon”…. Acknowledge things are rough…
  • Here’s how we’re tracking on the balance of the backlog related to this Epic/Feature/Goal.
  • “What do you think?”

Bob Schatz has a great post on the difference between a dead-end technical focused sprint demo, and one that breathes life into the event. Required reading, imho.

Additional Plot Lines

I recommend that teams review what they committed to, what they completed, and discuss the delta. What were the challenges the team faced, overcame, etc?

What were some of the key process improvements that were implemented to help achieve the sprint goal or remove some viscosity the team has been dealing with. What future actions planned? What amount of team capacity would the team like to devote to those activities. The team generally shouldn’t go into great detail here – a mention to highlight continual improvement should suffice.

Full transparency builds trust.

Practice Pragmatism, Not Dogma

There are some common “discussions” I have with my teams, the stakeholders, product owners and scrum masters regarding sprint review. The emergent/reoccurring themes are..

  • All stories completed must be demo’d” – To paraphrase Voltaire: The surest way to be boring is to leave nothing out. Focus on the customer, and potentially valuable feedback opportunities.
  • Only completed stories can be demo’d” – If an incomplete story is at a point where feedback could be obtained, go for it. Just acknowledge it’s not Done.
  • The Product Owner is seeing the completed stories for the first time – mini waterfall anyone? Feedback should have already been obtained within the sprint.
  • Stakeholder should sign-off at demo” – Ah, danger, Will Robinson. Typically, a team is working thru a number of “small” stories in an iteration, not one big one… Those stories all have clear a Definition of Done / Acceptance Criteria, and the Product Owner has seen “something” prior to the demo, right? The demo should not be a time of judgment. Any changes that emerge from stakeholder feedback go into backlog to be prioritized during planning…not holding up release and learning from putting things into use…
  • Then entire team must be at demo” – Daily stand ups mean the team knows what’s going on the entire iteration. While they are all welcome to attend the demo, they all don’t need to be there.
  • We have to prepare a great deal of stuff in advance – It’s a good idea to prepare a bit so the review runs smoothly, making sure there a sufficient test accounts and such. The time spent preparing for a demo should be as little a possible. Focus on connecting the dots between the iteration goals and a cohesive demonstration of the business value created.

Wrapping Up

  • Go into the review just as if you were doing a focus group with the end users of the ready to ship features.
  • Include work in progress if it is in a state where you can get feedback.
  • Show the value the team has created during the iteration.
  • And finally, look forward to refining the product backlog with what everyone has learned from the awesome review.

Read More

(Visited 330 times, 1 visits today)

Related Posts