Scrum Ceremonies: Sprint Review

Definition of the sprint review


The sprint review is held at the end of every sprint.  This where the team demonstrate the next increment of the product to be delivered.  The meeting is intentionally kept short and informal as the formalised part of  the review will have already taken place.  The way in which the meeting works best is to run the sprint review as a product demo where the new features that have been added during this iteration are presented to the audience.

Participants in the sprint review

The audience at the sprint review can be anybody who is interested in the latest developments to the product as well as the team.  I suggest that all the team are present and will explain why in a short while.

Preparation for the sprint review

I often advise teams not to spend hours and hours preparing for the sprint review, however it is always good to make sure that it goes according to plan; so it’s really a question of doing enough prep for the meeting to make sure everything runs smoothly.  I have sat in on some of the most embarrassing sprint reviews when senior management have been in attendance (isn’t it funny how it all goes wrong then);  the team have had a most successful sprint and then they get bad PR when the overhead projector or some other technical aspect of the demo doesn’t work.  So a tip, that seems so obvious so I ask myself why bother saying it, but turn up 10 minutes before the suggested start time and have a quick run through just to be certain of success.

Running the sprint review

So everyone is set up and you’re ready to go … I find that it is always useful to spent the first two minutes of the sprint review reminding (or informing because maybe everybody wasn’t aware) everybody of  what the sprint goal was; which part of the goals you achieved and thus what will be demonstrated in the sprint review today.  I often suggest that it is the Product Owner who gives this introduction, which is contrary to what Schwaber and Beedle suggest (they suggest the scrum master coordinates and conducts the review – Schwaber and Beedle, 2002, Agile Software Development with Scrum, Pearson education, p55) I’m happy to explain my reasoning behind this slight twist if anyone is interested.  This nicely sets the scene and give a professional feel about the sprint review.  Informal shouldn’t translate as unprofessional.

I always suggest that the Product Owner requests that if anyone has any questions to wait until the end of the demo.  If necessary the team can rerun the demo in order to address any key points or questions raised.  Of course this is optional and it may be easier for the teams to answer questions as they go, because there might be a lot to set up in order to rerun the demo; the Product Owner should explicitly state that preference at the start of the meeting.  This is because often visitors might feel that it is being rude to interrupt the flow, and sometimes it is, but if the rules and boundaries are set at the start of the meeting then usually all will fall into place.

So once the scene has been set the Product Owner can hand over to the team for the demo.

It is important to note that we only cover what has been completed and has been agreed by the Product Owner to have met the required quality standard for the product.  Anything that hasn’t been completed or “signed off” is not demonstrated.  Which leads me nicely onto the real purpose of the sprint review.

The real purpose of the sprint review …

I see that there are two reasons for the sprint review.  Firstly it offers the attendees the chance to understand and see for themselves the progress that has been made on the product.  It might be necessary for the Product Owner to discuss where this fits into the overall scope of the product delivery in the introduction at the start of the meeting.

Secondly the sprint review offers the team a chance to bring closure to their work for the  duration of the sprint.  The items or features that are demonstrated are considered to be closed and thus any outstanding requirements or other associated documentation is considered to also be closed.  This gives the team an opportunity to celebrate their success on meeting their goals and it is an opportunity for any senior management present to recognise and affirm the efforts of the team.  This is why I said earlier that it is important for all team members to be present; everyone needs to feel that sense of closure and completeness for the work carried out in the previous iteration.  Equally so, everyone deserves to share in the recognition of the work done to date.

What a sprint review is not …

      • It is not a meeting designed to critise or for the team to take further actions for improvement to the product. It should be noted that this meeting is an informational meeting that raises awareness of the goals achieved thus far   These are channelled through the product owner in the subsequent requirements gathering phase.  Therefore it is not a Go – No-Go meeting.  If the product is not considered fit for purpose before the review then my advise is to cancel the sprint review; the product owner can inform the necessary stakeholders as to why the product was considered to not meet the teams definition of done.
      • It is not death by PowerPoint.  I don’t like to be too directive on this point because PowerPoint does have its place; but the main focus should be on the demoing the product itself.  This is not always possible and some other means of demonstrating progress can be creatively considered without the use of PowerPoint.
      • It is not a document review meeting.  Documents are often a necessary output from the product development process.  If a document has been created it should be quality assured before the meeting and the smallest of introductions to identify where the document is stored and that it has been formally signed off according to the previously agreed definition of done.

Do you have any other tips for my other readers?

If you have any tips on how to run a successful sprint review then please submit them in the comment box below.  I will also give a link back to your site in return.  Thanks.



3 thoughts on “Scrum Ceremonies: Sprint Review

  1. Andrew

    I’m inclined to agree with you that the Product Owner should introduce this informal demo for the stakeholders, because (a) the PO has more of a bird’s eye view of the project, and (b) the PO is the primary connection between stakeholders and the dev team. Requirements flow to the dev team through the PO, so why not have finished product flow back to stakeholders through the PO once finished stories have been accepted? (Although I’m not saying that the team shouldn’t ever talk directly to stakeholders.)

    On the other hand, I think I can understand why others would say the SM should lead this meeting. Isn’t the SM’s role to facilitate the Scrum process and ensure that its rules and rituals are followed?

    I have limited experience with Scrum (as a developer and as a Scrum Master), and I am curious to know what your reasoning is for the PO leading this meeting. Thanks!

    1. Mark Buchan Post author

      Hi Andrew thanks for taking the time to reply – i’ll gladly jump on my soapbox so thanks for that opportunity ;0)

      My reasoning is much along the same line as yours Andrew, the product owner is responsible for the product so why wouldn’t they demonstrate that they are taking ownership by running the meeting.

      Another reason why I’m not keen on the scrum master (SM) running this particular ceremony is that it can often reinforce the command and control (C&C) type of management that is pervasive in PM circles. There is a line of thought that PM’s from the waterfall background should become SM’s in the Agile world and I’m never wholly convinced by this thinking. This is mainly because they often have the C&C mindset so deeply embedded that it can cause a hinderence to the team, the flow of work and the living of the values. So if you put this fella with that mindset “facilitating” the ceremonies you tend to have the “wrong” energy. I’m very much a believer in clear boundaries and I think the boundary of anything to do with product = PO role anything to do with facilitating team performance improvement = SM . Ok thats very black and white but in my experience this works better than muddy unclear boundaries that lead to confusion and noise, something that scrum was desinged to minimise. That is why I disagree with said authors opinion of who runs the sprint review, but all too often people believe that just cause its written in a book makes it right. People need to think more for themselves and experiment more which in fairness the authors do recommend.

      I hope this helps.


Leave a Reply

Your email address will not be published. Required fields are marked *