Who Should Perform the Sprint Review?

A concerned ScrumMaster came to me recently lamenting the fact that a Product Owner "ran" a sprint review.  My response was, "That isn't necessarily a bad thing."  The ScrumMaster then went on to describe how the PO in question directed everything in the meeting and didn't allow much discussion.  OK, so some context helps clarify things. :)

The question remains, though, is it always a bad thing for the Product Owner or Customer to perform the demo at the end of the iteration or sprint?

The Scrum Guide is certainly clear that the team performs the demo, but I come from the XP world where the Customer is involved on a daily basis (remember the 4th principle of the Agile Manifesto) and is seeing and accepting completed work as near to when it's completed as possible.  When that's the case, the demo is no longer for the benefit of the Product Owner but instead for the stakeholders outside of the team.

When I train & coach teams, I actively encourage them to have the Customer/PO perform the demo.  This, in turn, encourages the behaviour that the Customer is actively engaged with the team and that the work is truly done to the Customer's satisfaction such that they can present it to the stakeholders.  Since the Customer either is from or represents the business, the work completed is presented from that business perspective rather than from the team's technical perspective.  Being able to speak the same language as the stakeholders is a key aspect of this.

Of course, there is no absolute rule here.  I've seen many demos where the Customer sets the stage and the team members do the hands-on part.  For example, early in a system's development a development tool may be used to show that some background process worked because the stories behind that functionality had higher priority than the stories that would allow the system to show the results of the process.  The Customer may not know how to use the tool, but a team member does!

I've also seen demos performed by the team where the Customer is seeing the work for the first time at the demo, and they have gone just fine.  I've seen Customers who are more technical-facing than business-facing micromanage the work that the team is doing.  I've seen Customers who are completely disengaged and don't even show up to the demos, complaining many iterations later that the system doesn't do what they want.

In general, though, if your Customer or Product Owner is business-facing then I have found that work flows much more smoothly when that Customer is actively engaged with the team and is the person performing the demos.

I'm very interested in your thoughts... please comment!

Comments

test said…
We currently rotate the person who performs the sprint review through the team, including the Product Owner. This is an opportunity for all of the stakeholders to see what the team has produced, but the review isn't the first time the Product Owner sees the completed functionality as we review at least once with him before each story can be said to be 'done'. This promotes continual collaboration with the PO is something that we've found improves the outcome of each story.
I think it works best if the development team demonstrates the functionality they have made. This makes them feel proud and responsible. This is something that creates a special kind of focus. When they stand there demonstrating what they just made and see the smile in the audience faces they feel a special kind of ownership and proudness.

The PO invite the most interested stakeholders and start the meeting by summarizing what has been done. And what they didn´t succeed to do. And he takes notes :-)
Anonymous said…
Hi,

According to our findings, I agree that one of the biggest benefits of the review is to have a ceremony to celebrate what was done. It maintains a positive flow within the team, and keeps things going. It also helps setting a pace to iterative development, and promoting done done stories.

However, you don't necessarily get this by making developers demonstrate features. As long as you have a team that feels one, the team will be proud of what it did, whoever presents the work.

There's another option that we successfully use in some projects: make the testers demonstrate. They're in the middle of dev and PO, they must understand both aspects, and they already used the features. This can help having a more fluid review, e.g. if the product is a bit tricky to set up or use, which can happen in a complicated technical environment.