The end of the Sprint is marked by two events. One looks at what we have achieved as a team (Review); another looks at how we have achieved it (Retrospective). Both are times for inspection and adaptation, two of the pillars on which Scrum was built. Although they are usually performed consecutively, it is important to clearly differentiate the objective and purpose of each of the events.
The Review is also known as the “demo”. As stated in the Agile Manifesto, “Working software is the primary measure of progress.” (The manifesto uses the term “working software”, but Scrum interprets this to include other teams beyond software development teams.) So, it has become common for this event to resemble a “Show-and-Tell” for sharing results.
The Scrum Review Event
The maximum duration of a Review should be four hours for a month-long Sprint. With focus on only the work performed in the sprint, shorter sprints naturally will require less time for the Review.
Present Work Completed
Although the dwindling Scrum Guide no longer indicates it, showing actual results should take priority over an explanation whenever possible. This, of course, will depend on the nature of the activity that the team has been working on.
Because the demo is a common activity in software development (and is where Scrum emerged), it should be no surprise that the Review has taken on the task of demonstrating the working product. Today, the use of Scrum and its practices go well beyond software development, but the idea of “presenting” and not just telling what has been completed remains equally valid.
This moment of inspection and adaptation is a critical opportunity to collect feedback, as first-hand feedback is extremely valuable. For this reason, Scrum Reviews go beyond the Scrum Team to include important stakeholders.
Stakeholders are all parties or individuals who are interested in the team’s activity. Not all stakeholders are the same; the degree of interest can vary from highly engaged to indifferent or even uncaring. The same is true of the influence they may have on the team’s work.
Invite stakeholders to the Review who are considered “key”: those with the greatest interest and influence. For example, include your “sponsor” stakeholder, whose needs are prioritized and who provides resources for the product. You could also invite representatives from teams who have cross-dependencies, or even representatives from areas who have critical relationships to the product or service (legal, safety, etc.).
Discuss Next Steps
With the team and key stakeholders present, it is also important to discuss next steps for the upcoming Sprint during this event. The Scrum Guide emphasizes that the Sprint Review is meant to be a working meeting that is not limited to only presenting results.
If the team collects metrics (and they should, because we want to use data effectively), the Sprint Review is also a good time to review and share them transparently. Metrics can show the degree of progress and help properly manage stakeholders’ expectations so they know what to anticipate from future sprints. This is a way to adjust the roadmap and facilitate decision-making for the project’s evolution.
The Product Increment
The product increment is the result of activities performed (what we’ve “built”) during a Sprint and is what we analyze during the Review. Since the Sprint triggers the Review, you might be tempted to think that you shouldn’t release any results until the after the Review. However, this is not accurate. There may be several increments prior to the end of Sprint that can be delivered as they become available. Release them; the delivery of value should not be conditional on the occurrence of the Review.
Ultimately, a Sprint product increment is added to the previous increments so that they “work” together (whatever that means within the team’s work domain). The increment aligns with the Sprint goal and the product goal, and it meets the Definition of Done (DoD).
The DoD is a list of conditions that an increment must meet. The DoD can be standardized throughout the organization, or it might be specific to each team. Regardless, teams should have a thorough understanding of it in order to foster transparency. If the work performed does not comply with the DoD (usually a quality-based checklist), it is not considered a completed task and returns to the backlog.
The team should never present something as done that is not. Although it may be very tempting to please stakeholders and others attending the Sprint Review, simulating a degree of progress that is not genuine leads to mistrust. Furthermore, recovering that trust can be a long process, and it may never be rebuilt.
Instead, talk openly about what has not been finished and why. This is needed for stakeholders to be able to empathize with the team’s efforts, as it is easy to negatively judge the team or their progress when things do not go according to expectations. In order to promote this transparency, create a safe space to talk about the impediments and blockers that are affecting the team’s progress.
Sprint Review Responsibilities
According to the Scrum Guide, the people who are responsible and accountable for aspects of the Sprint should actively participate in the Reviews to which they’re invited.
The Product Owner has a special role as they must provide feedback to the stakeholders on the work completed. Again, there’s no need to wait until the Review to request feedback. The PO is available to the team, and at any time the team can discuss the status of an increment with them in order to make decisions about it.
The Scrum Master should do their best to ensure the event is fluid and meets expectations, much like all Sprint activities.
Developers actively participate in the meeting by ensuring that their work meets the Definition of Done.
In addition, as we have said, together with the Scrum team, stakeholders can also participate in the Review. They are not part of the basic Scrum “players”, but their contribution is essential. The team is not an isolated entity. They must establish relationships with other parts of the organization: various stakeholders, other teams and areas with which they have dependencies, possible support teams that provide the means for the work, customers and users, etc.
After the Sprint Review, there is only one more step before the Sprint is considered complete, and it is fundamental: the Sprint Retrospective.
Beyond the Sprint Review
Dig in to Scrum with our Agile Fundamentals course. Learn all the terminology, ceremonies, principles, techniques, and day-to-day application of Scrum. (And, earn your ICAgile ICP certification!)