Sprint Review
Sprint Reviews are a crucial point in a Scrum Project. The typical Sprint cycle is Sprint Planning —> Daily Stand Up meetings —> Sprint Retrospective —> Sprint Review.
Sprint Review is where the team demos the results of the Sprint to the Customer/Stakeholder group. Sprint Review is generally held on the last day of the Sprint or the first day of the next Sprint. It should be held before the Sprint Planning for the next Sprint. Generally, the team invites the Customers, Project Sponsor, Team Management, Stakeholders like Marketing, Production Support, Legal etc. to the Sprint Review. At the Sprint Review the team demonstrates working featiures that were produced in the Sprint and seeks feedback from the attendees. The team also informs the attendees of any changes to the Project or Release plan.
Why is the Sprint Review important or necessary when the Customer or Product Owner has been involved with the team (or even collocated) all along the Sprint?
Well, here are the reasons (in my opinion) why you should have a Sprint Review:
1. A Sprint Review signifies a formal end to the Sprint and focusses the team into completing some functionality which they can demo to the stakeholders. This helps create the habit of "we need to complete features". Many teams suffer from unfinished work at the end of a Sprint. To actually have to demo unfinished work is an unpleasant thought. A Review brings focus to the team.
2. Your Product Owner/Customer who is involved with the team may not be effectively communicating with the Project Sponsor or other Project stakeholders. You may find out that the Sponsor does not agree with the prioritization or the scope tradeoff decisions that your team has been making with the Product Owner. When would you like to find this out from the Sponsor? Every 3-4 weeks or at the end of the Project? Also, there may be other stakeholders in your project like smaller customer groups or Marketing or Legal etc. and your PO (Product Owner) may not be aware of the priorities of these groups. The Review is a great meeting to get everyone on the same page in terms of what was delivered, what was removed, what design tradeoffs were made, what is the velocity now and what looks in or out of scope in terms of the next Release or the overall Budget.
3. It is a great venue for the team to get some straight feedback from the Customers. A Scrum Master coming in a team room and saying "Jeff Corbin loved the features we delivered last Sprint" does not have the same impact as Jeff saying it in his own words at the Sprint Review. I've personally seen the motivating impact of first hand praise or even first hand rejection. It prevents rumors from starting and upholds the value of transparency that Scrum tries to foster.
What do I present in the Sprint Review?
- Have your team demo actual working features to the attendees. Seek their feedback. Let them drive the mouse/keyboard.
- Present Project Metrics, whatever you have, Velocity, Drag, Stories planned vs. completed, Test Coverage %, Build times, Release Burndown, Project Budget impact, Scope Changes (btw, try not to change scope within the Sprint, master the art of "lets keep that as a high priority for the next Sprint" :)
- Let the team members present one feature at a time, talk about it, show it, talk about the thought process in designing the feature and seek feedback on the ease of use etc.
- Talk a bit about what are the next high priority items (remember you haven't done a Sprint Planning yet, so don't commit to anything)
Should Sprint Review come before or after the Sprint Retrospective? I don't have a strong case one way or the other. If the Review comes before, then you have crucial data (Customer and Stakeholder feedback) that you can take to your Retrospective and that can change its course. If the Retrospective comes first, then you could have crucial data (Team feedback on challenges, successes and action items) that you can take to the Review meeting. In the second case, a stakeholder/manager attending the review could volunteer to help out with one of your challenges or action items. So you see, try both and figure for yourself which you like better or which works best in your case.
Article from Ken Schwaber on Sprint Reviews
A discussion on how to have a successful sprint review
To ask a question or leave a comment, please click the "discuss" link below.
