SCRUM Sprint Review the no PowerPoint Zone
Let’s start with the primary intent of a Sprint Review meeting it is for the team to demonstrate functionality that has been done during the sprint to the Product Owner and stakeholders.
It should not be a ”Dog and Pony Show”, but it shold be an opportunity for all those involved in the sprint to take pride in the work they have produced. So what does this really mean and what would be a good structure for a Sprint Review Meeting.
This means everyone involved in producing the functionality Developers, QA Engineers, and any sprint consultants – these could be User Experience, Architects, Operations Engineers, etc. Basically anyone who was a material part of the team during the sprint iteration, if you were part of creating the artifact then you should own and be proud of the result, sharing in the achievement.
The work the team has got done is demonstrated to the Product Owner primarily as the team is looking for final acceptance. Now I differ here from some SCRUM purists who would say you only produce features that are customer facing, for me value can be delivered to a customer in many forms other than direct user interfaces. In my view back-end performance, refactoring to improve system stability, etc. are all valid functionality as long as the intent of improving for you customer is kept as the reason and the improvement to the customer can be shown.
Delivering value to customers can take many forms:
- The simplest is often a customer facing feature, where you just show how it works in the product.
- It could be an API change, here the change in API should be shown in action. Not all demos have to involve fancy UI, this can be as simple as showing the functional tests against the API and the use case for its customer facing application.
- It could be a re-factor for performance, then showing the performance before and the performance after. Again the functional tests showing improvement would be perfect.
- It could be a defect fix, then again showing the test that demonstrates the corrected behavior is ideal and how this benefits the customer.
Demonstrations should be done on team workstations usually against a development or QA environment.
Such a small word but with implications that reverberate throughout SCRUM, “Done” is the essence of the entire SCRUM process. At the end of the day it is quite simple, have you finished the feature so that it is shippable to the customer?
If YES you are “done”. Designed, coded, tested, meeting intended need.
If NO for any reason you are not “done”.
Now it is very simple to get carried away on defining a checklist for “done” and trying to take in to account every single circumstance. To avoid this we need to always keep in mind the original intent which is to finished and be ready to ship, for this I like the following “done thinking grid” reference model.
“Done thinking grid”
Use this to cover the bases and define done in relatively simple steps that keeps the intent whole.
Preparation for the Sprint Review
This should take no longer than 1 hour and should be focused around the demonstration and artifacts that we used during the sprint to produce the work.
Producing additional artifacts like Powerpoints should not occur, basically if it was not useful in the sprint for the production of the functionality it should not be useful in the Sprint Review.
Sequence of a Sprint Review
- Team presents the goal of the sprint, the sprint backlog they committed too.
- Team members then briefly discuss what was ‘done’ and what was not.
- Remember this is not the retrospective so no deep dives.
- Demonstrate what was ‘Done’ Following the demonstration stakeholders are polled on their impression, issues with the backlog priority and what was delivered.
- Any input from the stakeholders is collated by the Product Owner and used for follow on discussions or backlog priority changes.
- At the end of the meeting the Scrummaster asks for acceptance from the product owner of what was delivered and if it should be shipped.
- The meeting is closed by the Scrummaster with the date and time of the next Sprint Review.
A sprint review should last long enough to complete a demonstration but as with all SCRUM meetings needs to be clearly time boxed and run in a concise manner, any topics that take too long should be tabled by the Scrummaster and followed up on later.