A product party

New Thinking 22 August 2014 Ceedee Doyle

The aim of the review is to delight our customers by showing working software (even the smallest bit!) and promote communication and feedback for us so that we can do a better job (and check we're going in the right direction). Your product owner will already have seen each item and signed it off (if not, why not?) to say that they are comfortable that what has been delivered does what they wanted it to do. The team and the product owner join together to show the wider world the stuff that got to Done (especially if it’s only the first cut).

Signs you have a good review:

• It is open to anyone who is interested

• It’s regular as clockwork, everyone knows when to show up

• Key people show up because they know you’re going to have stuff of interest to show them

• It is fronted by the product owner (so they are talking to their peers)

• There is a clear picture of where the completed stories fit into the big picture and how they are fulfilling the Product Owner's vision/roadmap

• Attendees tell you where you’re going wrong (feedback is what you want!)

• The Product Owner leaves with a fistful of new stories

We want to tell a story – from the user's point of view. What is the value they are getting out of this and how can we show it? it can be as simple as showing a soap UI input script (which they can edit) being sent off and an Excel spreadsheet connected to the database to show a plain database before and something different after.

Having said all that, it should take no more than a couple of hours on the morning of the review to put the thing together and it is far more important to have working stuff than pretty presentations.

So who can you invite to your product party?

For more on Sprint Reviews see:

The Dummies how-to (although I don't necessarily agree with their 'no ppt' suggestion!)

The Scrum Guide section of the Sprint Review