At the end of the sprint, the Product Owner, Team and Scrum Master meet to review the progress of the sprint. The product owner has to evaluate the state of the project so s/he can decide what to do next. How does the Product Owner ensure that s/he gets a complete and correct understanding about the state of the project, including all inconvenient truths? Here is a simple agenda/meeting template to follow, to make sure all the bases are covered.
Last week, I introduced that concept of a Sprint Contract to define the parameters of the sprint. The factors Scope, Quality, Time and Cost will be familiar to any project manager. Scope is defined by the stories and in particular their size. Quality is defined primarily by the definition of done. Time is fixed by the sprint duration. An upper limit on the costs is set by the team size * sprint duration, after adjusting for absences and other tasks.
A simple sprint review needs to
- Confirm that the team has delivered on its commitments
- Confirm that the overall project is on track
- Examine the functionality which has been delivered.
Confirm that the team has delivered on its commitments
The Scrum Master should take a few minutes to review and summarize the agreement between product owner and team. How many stories? How many story points? What is the definition of done? How much effort did the team plan to invest?
Next the Scrum Master should present a summary of what the team actually accomplished. How many stories achieved done? How many story points? Did the team invest more, less or the same effort as planned? If there were any important differences, now is the time to make them visible.
Confirm that the overall project is on track
The Release Burn Down chart is the primary tool for measuring progress and scope of the project. Scope, progress and estimated completion date are all clearly presented in one easy to interpret chart. Everyone in the project should see the update release burn down chart after each sprint. It's even better to keep it posted on the wall.
Is this enough? Beyond the basic burn down chart, it might useful to keep an eye on the other parameters of the project, i.e. quality and cost.
Monitoring quality builds confidence in the product and keeps your technical debt under scrutiny. The number of unit tests and acceptance tests defined and passed should increase every sprint. Insufficient tests are warnings that technical debt is accumulating or that requirements could change suddenly as the project nears completion. A rising number of open bugs may be a sign that the quality is not sufficient. Your next retrospective would be a good to time ask yourselves how to produce fewer bugs.
I think the main reason for monitoring work invested is to make sure that your teams efforts are not being diverted from the project. Monitoring budget in actual money will keep your top management happy and make your Product Owner's life easier. Budget can be tracked with a burn down chart, just like scope, and the budget divided by burn-rate should be sufficient to cover the remaining sprints.
Examine the functionality which has been delivered
Your team is only allowed to demonstrate finished functionality, i.e. meets the definition of done. My experience has been that trying to demo unfinished functionality causes trouble -- things which haven't been fully tested often break. Everyone should get a chance to talk, so each developer should demonstrate the functionality s/he was primarily responsible for.
As a product owner, you should ask questions and explore. This is a demo of product which your users will use, not a tour through the mine field. So everything you see should work or fail gracefully.
Once you've seen everything that is done, you can discuss briefly anything which was not successfully delivered. Why wasn't it delivered? What needs to be different, so that it can be completed in a future sprint? Or do you need to rethink?
The Simple Scrum Sprint Review Meeting
Here is a sample agenda for the meeting, with timings for a 2 week sprint.
Present: Product Owner, Implementation Team, Scrum Master
Moderation: Scrum-Master
Duration: 1 hour per week of sprint length
Agenda:
| What | Description | Who | Duration h:mm |
| Confirm that the team has delivered on its commitments | Review Sprint Contract | Scrum Master | 0:05 |
| Confirm that the project is on track | Review & Discuss Release Burndown Chart, other key points as needed | Scrum Master | 0:05 |
| Examine the functionality which has been delivered | A spontaneous guided tour, led by the developers, through the new functionality in the product. | Product Owner and Team | 1:40 |
| Discuss functionality which was committed but not finished | Understand what happened and why, but save deeper investigation for the retrospective | Product Owner and Team | Up to 0:10 |
via http://agilesoftwaredevelopment.com/blog/peterstev/simple-scrum-sprint-review
Posts
