Posts Tagged ‘sprint review’

Review, review

Posted: March 12, 2014 in Scrum
Tags: ,

One of the Scrum ceremonies I’ve focused on across both my Scrum teams is the Sprint Review (review). The basic/common use of the review is to demonstrate stories completed as part of the sprint. One of my team members called it a ‘dog and pony show’. Typically it is poorly attended by anyone other than the team, has some live demonstrations (if you’re lucky), and a lot of Powerpoint slides.

Although demonstrating working software is a very important part of the Sprint Review, it is not the only part. A Sprint Review is also supposed to be an opportunity for various stakeholders to review what has happened during the sprint and adjust the product/project vision accordingly. The whole point of agile (and lean) is to continuously learn and improve – and a sprint review is where you apply your learning to what you are building (and not how you are building it – this happens in the Retrospective).

More succinctly:

The point of a Sprint Review is to inspect the increment and adapt the Product Backlog. It is a collaborative working session, not a presentation. The Sprint Review is designed so that all attendees can inspect what has just been done in the current Sprint and then work together to discuss what the next optimal move is for the business. This means discussing the Product Backlog as it currently stands.

ScrumSense suggested the following agenda for a review (which I find a useful starting point):

  • Review the sprint outcome against the sprint goal
  • Demonstrate the functionality delivered (done stories only)
  • Focus on:
    • functionality “fit for purpose”
    • how the product could be improved
  • Discuss any challenges
  • Highlight technical debt encountered or incurred
  • Highlight impact of external factors (interruptions, team members off sick, etc.)
  • Discuss impact of what was learnt on the current priorities (or vision) (i.e. reviewing the overall backlog)
  • Choose the next Sprint Goal

Re the last item, although I think it’s a good idea to discuss the next main focus, I find a better place to agree and firm up the sprint goal is at the end of Sprint Planning I.

The diagram below also illustrates the intention and process of the sprint review nicely:


It is important to stick to the rule around only demonstrating done stories, otherwise your team may find itself in a downward spiral where they have to show ‘started’ stories further and further in the future as their done stories have already been inspected in earlier reviews (while they were not yet done). Some people choose to cancel reviews when there are no done stories from the sprint. I think it does depend on the situation, but there is a con to having the team feel that they don’t really have to deliver anything at the end of their sprint, and it is also often helpful to use the time to discuss why stories were not done. Usually there is a good reason and an opportunity to garner support to remove that impediment in the future. It also increases visibility with your stakeholders and, in the case where activities external to the team may impact the product vision (e.g. customer market research), the overall product review is still valuable.

The other challenge is who to invite. The ideal response is “the whole world”, but with space and time constraints as they are in most organisations, this is not always possible. We tend to adapt our audience based on what we are working on at the time and agree who to invite during planning. If your users and stakeholders are the same people and are seeing stories as work progresses (ideal), then it may feel that there is not as much value in showing the completed stories again. Again, value may still be derived in considering the bigger picture. I think there are cases where reviews probably can be cancelled or held less frequently, but that should be the exception rather than the rule and a responsible team and Scrum Master will question the need to not hold a review at the start of every sprint (at least).