Sprint Review
The Sprint Review provides an inspection of project progress at the end of every Sprint. Based on the inspection, adaptations can be made to the project. The team has estimated where it will be at the end of the Sprint and set its course accordingly. At the end of the Sprint, the team presents the product increment that it has been able to build. Management, customers, users, and the Product Owner assess the product increment. They listen to the tales the team has to tell about its journey during the Sprint. They hear what went wrong and what went right. They take a fix on where they really are on their voyage of building the product and system. After all of this, they are able to make an informed decision about what to do next. In other words, they determine the best course to take in order reach their intended destination.
During the meeting, everyone visualises the demonstrated product functionality working in the customer or user environment. As this is visualised, they consider what functionality might be added in the next Sprint. The product increment is the focal point for brainstorming. For example, someone could suggest the following after seeing the product increment demonstrated: "If we did controlled patient costs manually, we could use this right now in registration!" or "This would solve the problems that we're having tracking inventory in the districts. What would we have to do to make this work off the inventory database?" As the team demonstrates the product increment, it helps the attendees understand the weaknesses and strengths of the product increments, and the difficulties and successes it experienced pulling it together.
Sprint Review Rules
- The Team should not spend more than one hour preparing for the Sprint Review.
- Functionality that isn't "Done" cannot be presented.
- Artefacts that aren't functionality cannot be presented except when used in support of understanding the work products.
- Functionality should be presented on the Team members workstations and executed from the environment closest to production - usually a quality assurance environment.
- The Sprint Review starts with a Team member presenting the Sprint goal, the Product Backlog committed to, and the Product backlog completed. Different Team members can discuss what went well and what didn't go so well in the Sprint.
- The majority of the Sprint Review is spent with Team members presenting functionality, answering stakeholder questions regarding the presentation, and noting changes desired.
- At the end of the presentation, the stakeholders are polled, one by one, to get their impressions, any desired changes, and the priority of these changes.
- The Product Owner discusses with the stakeholders and the Team potential rearrangement of the Product Backlog based on the feedback.
- Stakeholders are free to voice any comments, observations, or criticisms regarding the increment of potential shippable product functionality between presentations.
- Stakeholders can identify functionality that wasn't delivered or wasn't delivered as expected and request that such functionality be placed in the Product Backlog for prioritisation.
- Stakeholders can identify any new functionality that occurs to them as they view the presentation and request that the functionality be added to the Product Backlog for prioritisation.
- The ScrumMaster should attempt to determine the number of people who expect to attend the Sprint Review meeting and setup the meeting to accommodate them.
- At the end of the Sprint Review meeting, the ScrumMaster announces the place and date for the next Sprint Review to the Product Owner and stakeholders.
Sprint Review Evaluation Consequences
Following a Sprint review certain consequences of the review may arise:
- Restoring unfinished functionality to the Product Backlog and prioritising it.
- Removing functionality from the Product Backlog that the Team unexpectedly completed.
- Working with the ScrumMaster to reformulate the Team.
- Reprioritising the Product Backlog to take advantage of opportunities that the demonstrated functionality presents.
- Ask for a Release Sprint to implement the demonstrated functionality, alone or with increments from previous Sprints.
- Choosing not to proceed further with the project and not authorising another Sprint.
- Requesting that the project progress be sped up by authorising additional Teams to work on the Product Backlog.
