Best Practices: Sprint Review

Are you getting enough value from your sprint reviews? Here are the best practices I share to Developers and POs

Purpose of Sprint Review

  • Inspect the outcome of the Sprint and determine future adaptations
    • Inspect the sprint and value delivered
    • Adapt the backlog and the release plans
  • Show progress toward the Product Goal
  • Share the business value delivered
    • Conversation on how value impacts the user
  • The main audience are the key stakeholders – business people and user representatives
  • Celebration of the achievement of the team

Structure of a Sprint Review

  • Introduction by the PO
    • Introduce new members if there are
    • Purpose of Sprint Review if it is the first time to conduct it (by Scrum Master)
    • Provide the context: Share print goal, Where we are with respect to the roadmap/product goal, Done and not done
  • Demonstration by Developers
    • Demonstrate the value that is delivered in the sprint
    • In case it’s a release to production sprint, demonstrate the value from the previous release to the new version
    • Gather feedback on the value delivered
  • Sharing what’s next by the PO
    • PO shares the next priorities and gathers feedback from the key stakeholders
  • Closing by PO/Scrum Master
    • Gather stakeholder feedback via survey

Tips and Best Practices for Developers (Demonstration)

  • Should avoid discussing implementation: how
    • As developers, we may have the tendency to show about the latest code, libraries, and framework we use. Leave it to the persons who might be interested in it like the guilds!
    • Avoid using technical jargon/terms that the key stakeholder would not understand. In case you have to, explain it in simple terms.
  • Should avoid discussing technical tasks unless it delivers business value to the key stakeholders
    • The possible business value that key stakeholders may appreciate include the improved response time of the application, responsiveness, usability, and the like
  • Limit the presentation deck, limit the time to a maximum of 15 minutes whenever appropriate
    • Have a live demo than a complete presentation deck
    • Limit to a list with at least 30 points font outlining the features to be demoed or 1 slide per feature with a title describing the value and the representative screenshot or flow, It can be an image representing the big picture of the feature being presented
    • Put only title, not whole explanation of problems. Talk about details, but do not write it because you will need to use 6pt fonts.
  • Reviews are informal, the tone of the meeting should be conversational
    • Like story-telling, best to arrange the features to be demoed in a certain order that makes sense
  • Showcase what was done, do not demo incomplete stories
  • Defects resolved that are not found in production are not demonstrated (e.g. defects in new stories implemented in the QA environment)
  • Prepare the inputs and configuration prior to the demo
    • Who would want to see login and setup or someone trying to look for the input files
  • Demonstrate the happy path by default
    • If there are edge cases that you need to show, have the screenshots rather than trying to reproduce them on the application
    • This can also engage the stakeholder as they try to think for cases that may break the application. Only show the alternate behaviors when they asked.
  • How to demonstrate features?
    • Describe the problem, pain or job, or gain and the persona related to it
    • Explain what is expected as the correct result
    • Demonstrate the functionality. Simple, straightforward
    • Ask for feedback
  • If you show performance improvements, compare them with the previous version. Don’t provide just %. Talk to us in milliseconds, a load of x thousands of users, etc.
  • The Developer who will perform the Demo should coordinate with the PO in building the agenda of the Sprint Review, confirm what to show and what not to show if uncertain.
  • Do rehearsals, with your peers, the team, or with the PO

Tips and Best Practices for the PO

  • Send a meeting agenda and a teaser of the features to be presented
  • Provide the context
  • Show the product backlog or an epic list
  • Plays the lead Emcee (facilitator)
  • Step in on business/domain questions during the demo of features
  • Show product metrics if available
  • Keep the meeting short
  • Share any risks foreseen such as technology changes that may impact the product

Share any best practices or tips on Sprint Review from the comment below.

– Agile Pinoy, Agile Filipino, Agile Pilipinas

Published by agilepinoy

We are Agile Pinoy. We believe that Filipinos can build globally competitive Products, one team at a time.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: