Sprint Review: Much More Than Just A Demo
If you're Sprint Reviews are more of a demo for the higher ups of the increment you're working on, then you're doing wrong. Learn how to get more from this Scrum ritual.
Join the DZone community and get the full member experience.Join For Free
Sprint Review or a Demo?
Many of those practicing Scrum mistakenly call the Sprint Review a Demo. Is it just a matter of terminology? From my point of view, the Sprint Review is the most underestimated Scrum Event, and for many companies, its potential is yet to be revealed. It is true that the Demonstration or Demo is an essential part of the Sprint Review, but it isn't the only one.
The Sprint Review is much more than just a Demo.
Let’s find out why.
Who Attends the Sprint Review:
The Scrum Team and stakeholders (users, other teams, managers, investors, sponsors, customers, etc.). One could say that we invite the whole world to the Sprint Review and this is absolutely true.
How the Sprint Review Is Conducted:
- The Product Owner opens the meeting and tells the attendees what the Development Team completed during the current Sprint (what has been "Done" and “not Done”).
- The Development Team demonstrates the "Done" functionality (Demo), answers any questions, and discusses problems they met on their way.
- The Product Owner discusses the current state of the Product Backlog, marketplace changes, and forecasts the likely release dates.
- The attendees collaborate on the Product Backlog Items, which can be completed during the next Sprint. Thus, the stakeholders get a shared understanding of the future work.
- A review of the budget, timeline, potential capabilities follows.
The Opportunity to Inspect and Adapt
The Sprint is one of the five official Scrum Events and is an opportunity for the Scrum Team to practice empiricism. Here is a short summary of what we inspect and adapt during the Sprint Review.
Inspect: Sprint, Product Backlog, Increment, Marketplace, Budget, Timeline, Capabilities.
Adapt: Product Backlog, Release Plan.
Inspecting Is Much More Than Just an Increment
The Sprint Review is not just about product demonstration, it is an inspection of the completed Sprint, the Product Backlog, and the marketplace. Also, it is a place for reviewing budgets, timelines, and capabilities. Each Sprint is an important risk mitigation tool and the Sprint Review is a decision point for the Product Owner.
Each Sprint can be the last one. The Product Owner makes a formal decision regarding financing the next Sprint during the Sprint Review.
Here are some decisions that can be formally made:
- Stopping/pausing the development.
- Financing the next Sprint.
- Adding team(s) with an assumption that it will speed up the development.
- Releasing increments (can be done anytime during the Sprint).
Is My Sprint Review Good Enough?
Scrum is based on iterative and incremental development principles, which means getting feedback and making continuous updates to the Product Backlog. Unfortunately, teams often forget about it.
The Sprint Review is a great tool for getting feedback, while the number of changes to the Product Backlog after the Sprint Review can be an important indicator of how healthy your Scrum is.
Why Many Scrum Teams Don't Go Beyond Demo
Many teams/companies underutilize the entrepreneurial spirit of Scrum and its concept of the Product Owner as a mini-CEO of the Product. Very often, stakeholders attend only the Increment demonstration (usually done using a projector) with few questions asked and then everybody leaves shortly afterward. This may happen for several reasons:
- The Product Owner doesn't actually "own" the product, cannot optimize the ROI or make strategic decisions about the product, and is, in fact, a Fake Product Owner (FPO). During the Sprint Review, stakeholders (with actual Product Owners among them) often "accept" the Scrum Team's work.
- The company's business and development departments continue to play the "contract game" with a predefined scope and completion dates. In this case, the Sprint Review inevitably becomes a status meeting.
- Superficial Scrum implementation at the company.
- The Product Owner doesn't collaborate enough with stakeholders.
- This is a case of “fake Scrum,” when the Scrum Team handles only a part of the system with inputs and outputs and not the real product. There is nothing to show and nothing to give feedback on.
Good Sprint Review Practices
- An informal gathering with coffee and cookies that looks more like a meetup, often held as an Expo or a Review Bazaar.
- The Product Backlog is updated after/during the Sprint Review.
- The meeting is often attended by end-users.
- The Development Team communicates directly with end-users and stakeholders and gets direct feedback from them.
- The "Done" product is showcased on workstations where the stakeholders can play with the new functionality.
Signs of an Unhealthy Sprint Review
- A formal/status meeting.
- The new functionality is demonstrated only in a slide show.
- The Product Owner "accepts" the work completed by the Development Team.
- The Development Team isn't (fully) present.
- Neither are stakeholders and/or end-users.
- The demonstrated functionality does not meet the Definition of “Done.”
- The Product Backlog is not updated. The Scrum Team works with a predefined scope.
- The stakeholders "accept" the completed work from the Product Owner.
The Bottom Line
Well, I wrote quite a lot. Let's sum it up.
- The Sprint Review is more than just a Demo. The Sprint Review is a place to discuss the marketplace changes, examine the completed Sprint as an event, update the release schedule, discuss the Product Backlog and the possible focus for the next Sprint. This is where the dialog between the Scrum Team and the stakeholders takes place and feedback on product Increments is obtained.
- The number of changes to the Product Backlog can be an important sign of how healthy your Scrum is.
Published at DZone with permission of Ilia Pavlichenko, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Transactional Outbox Patterns Step by Step With Spring and Kotlin
Logging Best Practices Revisited [Video]
DevOps Midwest: A Community Event Full of DevSecOps Best Practices