Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


Sprint Review Tips

In my tips articles, I try to describe highly effective ways to fulfill the Scrum framework. The Scrum framework intentionally leaves holes that are opportunities for teams to fulfill the framework in the way that is best for a particular team's circumstances. The Scrum Guide defines the Scrum framework, and my tips are in no way meant to define or re-define Scrum. My tips are based on my numerous Scrum coaching experiences, and I believe them to be consistent with the Scrum Guide.

  • First, foremost, and most importantly, know what a Sprint Review is supposed to be. Read the Scrum Guide, it's only like 20 pages. Specifically, read the section on the Sprint Review and make sure your team is in alignment with the Sprint Review as it is described in the guide.
  • It is a worst practice to use the Sprint Review as a signoff or user acceptance meeting.
  • Make the demo be an informal one, maybe even done on a developer's machine, but make sure that it is visible by all at the meeting (project it onto a big screen if need be).
  • Spend no more than 1 person hour preparing for the demo.
  • Remember that a Sprint Review is much more than just a demo.
  • Time-boxed to 1 hour per per week of Sprint length
    • (i.e. 2 week sprint = 2 hours, 4 week sprint = 4 hours, and so on)
    • As with all Timeboxes, just because the Time-box is X hours, don't feel like you have to spend X hours on the meeting. Respect the value of your stakeholders' time, but still make sure you accomplish the Sprint Review agenda.
      • Different teams will have differing needs as far as how much detail to go into during the Sprint Review. Tune your approach according to the needs of the attendees.
  • Have your Product Owner play the "lead emcee" role in the Sprint Review.
  • Have the ScrumMaster be a silent observer in the Sprint Review. Ok, maybe not a silent observer, but at least a role where they only get involved in the review if it's absolutely necessary to clarify Scrum roles, rules, or principles.
  • Treat all feedback as welcome feedback, especially from stakeholders.
  • Treat the Sprint Review as if you were doing a focus group on your just completed features. Be curious about any hint of feedback, and ask for suggestions from everyone (including developers) on how to gain more value from the current and future features.
  • Never say "no" outright to a new feature or enhancement request. Always put it on the backlog. It may go way down in priority on the backlog, but put it there. You might word the backlog item slightly differently than the suggester did, but put it there. Try to word it as a request for functionality or request to solve a problem ("the what")rather than a "do it this way" command("the how").
  • Any feedback that results in changes to be implemented is a new Product Backlog Item.
  • Make sure the right stakeholders are present. Generally speaking this is a responsibility of the Product Owner(Provides vision) and the ScrumMaster(Resolves impediments).

Related articles:


coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg