Tips for a Good Sprint Review


Sprint Review Tips

These tips are not a part of Scrum according to the Scrum Guide. They are my own personal tips based on my Scrum Coaching experiences. I do believe these tips are 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.
  • Spend no more than 1 person hour preparing for the demo.
  • 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.
  • 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.

 

Related articles:

About these ads

2 Responses

  1. Hi,
    I found your blog looking for an answer to a problem we have preparing the sprint review.

    In your post you say “Spend no more than 1 person hour preparing for the demo.” but how can you do that?

    In our team the review is done by a team member. But if you are developing until the last day (previous to the review), this person must have some time to prepare some examples to show the new functionalities to the Product Owner. Right now we need at least one day to prepare the review. I know this is unacceptable but we don’t know how to improve it.

    Could you give us some advice?

    P.S.- Thank you for your blog. We got some very interesting points we needed to improve :)

  2. Daniel,

    (Thanks for the comment!)

    First, while it is definitely important to show at least a couple of representative examples of each “done” backlog item, you don’t need to show every single path through every new feature.

    Second, looking back on it, my advice about one person hour is probably not great advice. (In my defense, I got it from somewhere else I think — maybe Mike Cohn?) If I were to re-write it today, I would probably say something like — For a 2 week sprint, try to spend no more than about 2 person hours prepping for the Sprint Review. Adjust proportionally for sprints of different lengths. The demo in the Sprint Review is not meant to be a “formal big production/effort.” It’s meant to be an informal demonstration of “done” features to spur good feedback and good input for the upcoming Sprint(and Sprint Planning meeting).

    Daniel, a couple of other questions that might shed some light on the root cause of the problem.
    1. How big is your Scrum team?
    2. How long are your sprints?
    3. Do you often have a lot of stories being “accepted” on the last day of the sprint? If so, what is preventing you from getting “acceptance” earlier in the sprint?
    4. Has the team discussed this difficulty in a retro? If so, what do they think would help this situation?
    5. Often times people who are focused on testing are good team members to run demos as they sometimes exercise the app as a user more often than programmers. Is the team member who does your demos a tester, programmer, or some other functional role?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 255 other followers

%d bloggers like this: