Scrum Event, The Sprint Review

What is sprint review

review

Sprint Review meeting is an informal meeting and not a status meeting. The purpose of this meeting is to elicit feedback and foster collaboration. It’s the place where the product is inspected and adapted to make the most impact for the business. Participants collaborate about what was done in the iteration and what needs to be changed in order to optimise the business value.

Who should participate?

Participants in the sprint review meeting should be the Product Owner, the Development Teamthe Scrum Master and any stakeholders that their feedback will have positive impact on product backlog and on any decision need to be made that their opinion matters.

What you typically do as Product Owner

  • You need to present what was the sprint goal that was determined during sprint planning and all the User Stories related to that goal – transparency
  • You need to share an overview of the product increment that was actually achieved and in a blame-free environment explain the reasons why you couldn’t achieve the sprint goal if this is the case.
  • You need to collaboratively decide whether the product increment is *ready to be released and shipped *considering the business value will provide to end users.
  • You are responsible to accept or reject the user stories forecasted to be delivered by the development team. The decision should be based on the fulfilment of the acceptance criteria and the definition of done
  • You need to review the timelineupdate and show your product release plan based on the amount of User Stories accepted. Show the latest status of of release burnup/down chart. Note that the sprint review it’s not a formal meeting that you approve the work. This should be done earlier and during the sprint.

Being transparent and creating awareness of all issues is the first step to resolve them! Remember once more that this is not a status report meeting but a meeting to discuss, collaborate and get the support and feedback required to resolve all known issues that prevents you in reaching your sprint goals!

tips Identifying a core group from the beginning that should be always at sprint review might help! Consider even to invite specific stakeholders on a sprint by sprint basis! What about end users representatives? Think of them as well! Their feedback matters!

What you typically do as Development Team

  • Don’t wait until the end of the sprint to demonstrate all the committed user stories but do that throughout the sprint. The idea is to get feedback as fast as possible and have the time to make the necessary changes. During the review demonstrate a selection of acceptance criteria that could give an overview to all stakeholders how the increment behaves.
  • Make sure that your increment* fulfils the criteria you have collaboratively set in the Definition of Done.* It’s up to the product owner to accept or reject undone work.
  • Be open to get the feedback from stakeholders and the product owner and demonstrate the commitment required to make all the required changes in your increment.
  • Ask questions to stakeholders related to product strategy, market needs, business value. It will help you better understand what need to be developed and will bring you closer to business people.
  • Discuss the problems came up and resolved during the development of the user stories and the problems that impeded us to reach your sprint goal

Working software is the measure of progress and success. So instead of creating fancy presentations related to your product increment, demonstrate a working product increment!

tips It is best not to release undone work. when this is the case make it visible to your product backlog, define it, know the size and commit to done this work in the upcoming sprint

What you typically do as Scrum Master

  • Make sure to keep it timeboxed! For a two-week sprints 2 hours will be enough!
  • Help the Product Owner in organising the meeting and make sure that stakeholders will be present
  • Make the right questions to maximise learning, trigger feedback while secure that blame storming is avoided.

What you typically do as Stakeholder

  • You bring the latest information related to market needs, strategy and business goals. This information will help to discuss and collaborate on what needs to be developed next.
  • Give feedback on what you see. Do you like it? What is being build is close to desired business results? Is sth missing? Or even do you think that there is an over investment of specific features?
  • Answer all the questions coming form the development team and the product owner. Your feedback will help them build the right thing and will enforce the collaboration wth the IT people.

Common anti-patterns

The sprint review meeting is where the product increment is demoed for the first time and the product owner approve the user stories

It might happen but it is not recommended. The idea is simple! We should try always to shorten our feedback loops because we learn from them. Demonstrating a work at the end of the sprint is not giving you much time to implement required changes and you might come to a situation that you cannot deliver sth valuable!
Try to demonstrate a done user story as soon as it is ready and fulfil your Definition of Done criteria.
In addition making a demo prior the review, could be seen as a “dry run” activity. Who wants to demonstrate a supposed to be working software infant of the stakeholders for the first time?

We demonstrate only DONE user stories

Remember again that it is important to get fast feedback. So it’s up to the the Product Onwer to decide if there is value in demonstrating not DONE work. If there is need to have quick feedback then do so! Demonstrate your work even if it’s not DONE.
Note that undone work should be of known size, well defined and should be visible to the product backlog if for some reason it’s not possible to implemented within the current sprint

The product backlog based on the feedback received changes radically after each sprint review

Well, depends. If the changes need to happen for the upcoming sprint then it’s a good idea to make the changes right after the sprint review so to have the backlog refined for the upcoming sprint planning. If the changes will affect future sprints, then keep the notes and make sure to make the changes in during the backlog refinement meetings

It is just enough that the development team and the product owner participate in that sprint review meeting

Yes it’s about the stakeholders! Usually they have so many other high-priorities meetings and no time for the sprint review or even they do not believe that the team could produce something valuable in just a few weeks! These are known dysfunctions
Surprise them positively by demonstrating valuable working software and you will gain their attention to participate in the sprint review where the highest priority products are being demonstrated!

Scrum Master reporting for the team using fancy presentations

I’ve seen this happening! Nice reports prepared by the Scrum Masters and presented to the product owner and all stakeholders! A typical status report meeting! Avoid it and follow what prescribed above!

 

Iteration review checklist (example)

screen-shot-2016-06-21-at-10-50-40

Learning Path

Posts & Articles

What the hell is the sprint review meeting

Tips for a good sprint review meeting

6 common misconceptions and anti-patterns of the sprint review meeting

Advertisements