The Anatomy of a Sprint Review - Introduction
We like Sprint Review, we show things, working things and have collaborative discussions about what we show, but is this all about showing? Is this all about playing out with our iteration? Or is it more?
Let's recap the purpose of the Sprint Review:
Based on what was done during the Sprint, attendees collaborate on the next Product Backlog Items from the Product Backlog that could be done to optimise the value of the Product. The presentation increment (Sprint Review) is intended to elicit feedback and foster collaboration, hence the entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
During the Sprint Review we might want some inputs from our Stakeholders, like sharing and giving information about:
- How the marketplace or potential use of the product might have changed and what is now the most valuable thing to do next
- The timeline, budget, potential capabilities and marketplace for the next anticipated releases of functionality and capability of the product
- How the marketplace looks like (and after this, shall we change the Product Backlog?)
- holidays, special events..
- organizational periodical (new laws that come in and change your product, competitors updates ..)
Results we expect to come out from a Sprint Review according to my experience and researches are the following:
- A revised Product Backlog that defines the probable Product Backlog Items for the next Sprint. Product Backlog may also be adjusted overall to meet new opportunities.
- Reshape the "vision" for the product (during sprint iteration we get too much technical and we forget about the vision and the sprint goal)
- Briefly, BRIEFLY, discuss the sprint itself (what went well, what problems we faced, show the increment), give stakeholder ability to try the increment with their hand (tablet, macbook..)
- After the Product Owner shows the current state of the Product Backlog, we ask ourselves: shall we change something or continue like this?
- The only one question to make constantly is: should we change the Product Backlog? Priorities?
In a perfect world, the Sprint Review should look like this:
- "PO" owns the meeting, send invitation, put Product Backlog on the wall, open the session and tell Stakeholders the overall sprint burn down
- "Development Team" briefly show the results (what actually is done)
- "Stakeholders" try out physically the product and the passive lookers notes down observations
How much time should a Sprint Review last? At most two-hour meeting for two-week Sprints.
So what is the anatomy of your Sprint Reviews?
Hope this might have helped you to bring more clearance on Sprint Reviews and how you might get them to the next level in your organisation. Thank you for reading!
