Executive Summary: The Sprint Review

Summarized directly from the Scrum Guide.


  • Informal meeting
  • Present work just completed(demo)
  • Collaborate on work just completed in the current Sprint
  • Use work completed and current state of Product Backlog to collaborate about what to do in the next Sprint

Minimal Requirements of the Sprint Review

  • 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)
  • Attendees: Entire Scrum Team + Stakeholders
  • Agenda
    • Product Owner identifies what has been done and what has not been done
    • Development Team:
      • Talks about the Sprint
        • what went well
        • problems that arose
        • how it solved those problems
      • Demonstrates completed work/Product Backlog Items
      • Answers any questions
    • Product Owner:
      • discusses current snapshot of Product Backlog
      • projects likely completion dates with various completion rate(or velocity) assumptions
    • All attendees then discuss previous agenda items and how they affect what to do next
      • Provides vital input into the impending Sprint Planning Meeting

Related articles:

Worst Practice: The Sprint Review as a Signoff Meeting


One of the “worst practices” I’ve discovered several times when coaching Scrum teams is when a team uses their Sprint Review as a “signoff” meeting, with either the Product Owner or other stakeholders acting as approvers. Getting feedback at a Sprint Review is great, but treating the Sprint Review (some call it a “Demo”, a mistake in my opinion) as some sort of acceptance meeting causes all kinds of problems. In this article, I look deeper at this worst practice from the following angles:

  • Possible Symptoms
  • Possible Causes
  • Possible Consequences
  • Possible Solutions

Link to full article

I encourage you to comment on the full article here on the blog, as every comment posted helps me and others to improve their knowledge of Scrum.

%d bloggers like this: