Is it better to do a Sprint Review or a Demo?
Many Scrum practitioners wrongly refer to the Sprint Review as a Demo. Is it merely a question of terminology? The Sprint Review, in my opinion, is the most undervalued Scrum Event, and its full potential has yet to be realized for many organizations. True, the Demonstration or Demo is an important component of the Sprint Review, but it is far from the only one.
The Sprint Review is far more than a demonstration.
Let’s investigate why.
The Sprint Review is open to the Scrum Team and other stakeholders (users, other teams, managers, investors, sponsors, customers, etc.) We could say that the Sprint Review is open to everyone in the world, and we’d be correct.
The Sprint Review is conducted as follows:
- The Product Owner welcomes the attendees and informs them of the Development Team’s achievements during the current Sprint (what was “Done” and “Not Done”).
- The Development Team presents a demonstration of the “Done” capability (Demo), answers questions, and discusses any challenges that arose along the way.
- The Product Owner discusses the current state of the Product Backlog, market changes, and anticipated release dates.
- The participants collaborate on Product Backlog Items that can be finished in the next Sprint. As a result, everyone engaged is on the same page about what needs to be done in the future.
- Following that, there will be an assessment of the budget, timeline, and prospective capabilities.
The Ability To Examine And Adapt
Sprint is one of the five formal Scrum Events, and it allows the Scrum Team to put their empiricism to the test. Here’s a quick rundown of what we look at and change during the Sprint Review.
Sprint, Product Backlog, Increment, Marketplace, Budget, Timeline, and Capabilities are all things to look at.
Adapt the following: Product Backlog and Release Plan.
Inspecting Isn’t Just A Step In The Right Direction.
The Sprint Review is more than simply a product demo; it’s also an examination of the finished Sprint, the Product Backlog, and the market. It’s also a location to go through finances, timelines, and capabilities. The Sprint Review is a decision point for the Product Owner, and each Sprint is an important risk mitigation tool.
Each Sprint has the potential to be the final one. During the Sprint Review, the Product Owner makes a formal choice on funding the following Sprint.
Here are some formal decisions that can be made:
- The development is being halted or paused.
- Getting the Next Sprint Funded
- Adding team(s) with the expectation of speeding up development
- Releasing Increment is a term that refers to the process of releasing (can be done anytime during the Sprint)
Is My Sprint Review Appropriate?
Scrum is built on the ideas of iterative and incremental development, which involves gathering input and updating the Product Backlog on a regular basis. Unfortunately, many teams overlook it.
The Sprint Review is an excellent method for gathering input, and the number of changes made to the Product Backlog following the Sprint Review can be a good measure of how well your Scrum is working.
Why Do So Few Scrum Teams Go Beyond Demo?
Many teams/companies fail to capitalize on Scrum’s entrepreneurial spirit and concept of the Product Owner as a mini-CEO. Frequently, stakeholders attend only the Increment demonstration (which is usually done using a projector) and then depart shortly afterward. This could occur for several reasons::
- The Product Owner is a Fake Product Owner since he or she doesn’t genuinely “own” the product, can’t optimize the ROI, and can’t make strategic decisions about it (FPO). Stakeholders (including the actual Product Owner) frequently “approve” the Scrum Team’s work during the Sprint Review.
- The company’s business and development departments are still playing the “contract game,” with predetermined scope and deadlines. The Sprint Review will eventually devolve into a status meeting in this instance.
- Scrum implementation at the organization is only on the surface.
- The Product Owner does not engage in enough stakeholder collaboration.
- This is an example of “fake Scrum,” in which the Scrum Team is only responsible for a portion of the system, such as inputs and outputs, rather than the entire product. There’s nothing to show and nothing on which to comment.
Sprint Review Best Practices
- An Expo or a Review Bazaar is a casual get-together with coffee and cookies that looks more like a meetup.
- Product Backlog is updated after or during the Sprint Review.
- End-users frequently attend the conference.
- The Development Team connects with end-users and stakeholders directly and receives direct input.
- The “Done” product is shown on workstations so that stakeholders can experiment with the new features.
Review of Signs of an Unhealthy Sprint
- A status/formal meeting.
- Only a slide show is used to explain the new features.
- The Development Team’s work is “accepted” by the Product Owner.
- The Development Team (as a whole) isn’t present.
- Stakeholders and/or end-users aren’t either.
- The functionality demonstrated does not fulfill the definition of “done.”
- The Product Backlog hasn’t been updated in a while. The Scrum Team works within a set of parameters.
- The stakeholders “accept” the Product Owner’s completed work.
Final Thoughts
The Sprint Review isn’t merely a demonstration. The Sprint Review is a meeting where you can evaluate market changes, look back on the completed Sprint as an event, update the release calendar, talk about the Product Backlog, and decide on the next Sprint’s focus. This is where the Scrum Team and stakeholders communicate and receive feedback on product increments.
The quantity of Product Backlog modifications might be a good indicator of how healthy your Scrum is.
Author :
