Overview of the Sprint Review

During sprint planning, the scrum team creates the work plan. This plan is summarized in the Sprint Backlog. The plan then guides the work done during the sprint. Then, once the work is done a sprint review is scheduled. It is an opportunity for users to examine the outcome, ask questions, and make suggestions.

Review the Results

Each sprint, or a collection of sprints, is expected to deliver a potentially shippable product. So it does make sense that, at the end of these sprints, there would be a formal opportunity for end users or customers to review the results. This step is yet another example of how scrum is an adaptive and user-driven approach to project management.

Demonstrating the Work “Done”

The purpose of a sprint review is to demonstrate the work that has been done during the sprint and to provide stakeholders with the opportunity to examine the results and compare them to the expectations expressed in the vision statement, user stories, product backlog, and sprint plan. It is an opportunity to provide a transparent look at what has been done and how those efforts meet these expectations. Many consider this step the most important step in the scrum process. It is an opportunity to adjust and make changes before it is too late and attention turns to the next sprint.

Feedback for the Next Sprint

As a result of this review, stakeholders will have the opportunity to express what they like about the results, what they don't like, and the changes they would recommend to ensure a better outcome. as such, the feedback gained from this process is an essential factor in the iterative process that helps to ensure a successful final result.

Who Should Attend?

The product owner, scrum master, and project team represent the core of those who attend the session. They are the ones who need to hear the concerns of other stakeholders since they are the ones who will be responsible for taking any necessary action. both internal and external stakeholders should attend when appropriate. Internal stakeholders are those within the organization to whom the project results will be delivered. They may include representatives from the supply chain department, accounting department, or marketing department. External stakeholders include customers or clients. However, it may not be necessary to invite those stakeholders for every meeting. The object is to encourage a wide range of stakeholders to attend and also to encourage them to express their concerns as the project moves towards completion.

Meeting Roles

Product owners usually run the review meeting. They begin with a summary of the sprint goals. This is followed by a demonstration of the product, usually under the direction of the project team. In addition, the product owner takes notes, recording the comments of stakeholders and the responses by the team. The Scrum Master serves in a supportive role and encourages that the room includes the necessary equipment to support the demonstration and that the project team is prepared to start on time as well as finish on time.

How Long Should the Sprint Review Last?

To keep within the context of timeboxed meetings, which are purposely kept short, a sprint review should also be scheduled with the same constraint in mind. In general, a meeting time of one hour should be scheduled for a sprint that has taken one week. For sprints that have taken two weeks, a two-hour time slot should be adequate. In short, the meeting length should be one hour for each week a sprint lasted.

Outcome Goals

The outcome of the meeting must be such that everyone in attendance feels that they have had an opportunity to ask questions and that their questions have been answered to their satisfaction.

Examples of Questions

There are many questions that might arise during these meetings, but there are a few that are a must.

• Do the internal and external stakeholders approve of what they see?

• What changes would be recommended to improve the final outcome?

• Does the vision still hold?

• Are we still addressing an important need in the marketplace?

• Are there features we may be missing?

• are we doing work and creating features that will ultimately have little payoff?

Sprint Review Fatigue

There is a challenge that scrum professionals routinely express. That challenge is to maintain attendance to review sessions. Yes, end user or customers are busy people. What they would prefer is to present the product owner with the requirements that have to be met and then assume that the team delivers exactly what is needed. Many, perhaps most, prefer not to be bothered with Sprint reviews. And if they do attend the early reviews, many scrum masters complain that interest in the review wanes as the project moves towards completion and attendance falls.

Without these stakeholders attending, the basic principle of customer driven development suffers a significant blow. Accordingly, the scrum team needs to make these sessions as interesting and short as possible. Needless to say, this is a challenge of considerable proportions.

Sprint Review and the Next Sprint

The main goal of these sessions is to adapt when necessary. Now is the time for the team, in conjunction with other stakeholders, to discuss what needs to change as they prepare to move into the next Sprint planning session.

Sprint Review and Scope Creep

A very real possibility, one that seems to be emphasized more in waterfall than in scrum, is scope creep. Scope creep occurs when new features are requirements are added to a project beyond those which have originally been approved. The Sprint review is a perfect opportunity for scope creep to occur. Here is how it works. When end users explore a sprint outcome, they see a concrete example of the vision, or part of the vision, from a new perspective. by actually experiencing the products features, they often come up with new ideas or new features they feel will further improve the product's value. They may insist that these changes will better address customer and market needs.

Whether or not the new request can be accommodated depends upon several factors, not the least of which is the expected value that the additional scope will bring to the product, how much more it will cost, and how much longer it will take. to authorize scope creep is a difficult decision and needs to be made in conjunction with the product owner, scrum master, and project team. The final decision is made by the product owner and, when the changes significant, it must be made by top management. In most situations, scope creep is discouraged.