Sprint Review

• Inspect the increment, and adapt PB if needed (determine future adaptations)
• Scrum Team presents results of the work to key stakeholders & progress toward the Product Goal is discussed
• review what was accomplished, what has changed in their environment, based on this information, attendees collaborate on what to do next and PB may be adjusted
• It is a working session, not a presentation or demo
• No need to wait for the Sprint Review for releasing: Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value
• If a PBI does not meet the DoD, it cannot be released/presented at the Sprint Review. It returns to the PB for future consideration
• Characteristics
  • Participants: Scrum team and Key stakeholders invited by the PO (users, other teams, managers, investors, sponsors, customers, etc.)
  • Time-box: maximum of 4 hours for a 1-month Sprint. For shorter Sprints, usually shorter
  • Structure
    • 1. The PO explains what PBIs have been “Done” and what has not been “Done”
    • 2. The Developers discuss what went well during the Sprint, what problems it ran into, and how those problems were solved
    • 3. The Developers demonstrate the work that it has “Done” and answers questions about the Increment
    • 4. The PO discusses the PB as it stands. He/she projects likely target and delivery/release dates based on progress to date (if needed)
    • 5 or 6. The entire group collaborates on
      • what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
      • PBIs which can be completed during the next Sprint. Thus, the stakeholders get a shared understanding of the future work
    • 6 or 5. Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next
    • 7. Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality and capability of the product
  • Purpose
    • to inspect the outcome of the Sprint and determine future adaptations
    • Inspect Increment, marketplace, and decide what to do next
• Inputs: Increment, PB, …
• Outputs: a revised PB that defines the probable PBIs for the next Sprint, maybe also adjusted overall to meet new opportunities
• 5 Characteristics of a Great Sprint Review
  • Stakeholders are difficult to recognize
  • Every Developer Participates
  • Feedback. Feedback. Feedback
  • A Tailor-Made Sprint Review
  • Beer & Bitterballen
• Ordering PBIs potentially added to next Sprint
  • Buy a Feature
  • 20/20 Vision
  • Pass the cards
• NOTE: no such thing as a rejected backlog item:
  • The Scrum Guide 2017 mentions nothing of rejecting anything at the Sprint Review
  • Done Increment: then the Development Team did everything they were required to do. there is no rejection of the PBI there is only feedback. There is just a learning opportunity that can be used to reduce the expectations gap for future Sprints. Reflect on that during the Sprint Review, engage with Stakeholders to better understand both their intent and their expectations
  • Since the only constant is change, it is absolutely possible that the Scrum Team created something that meets Done, meets the Acceptance Criteria, and still does not meet the needs of the business. Is this the Development Teams fault? Of course, not… it is a learning point, and inspect and adaption of understanding between the Scrum Team and the Stakeholders
  • At the end of the Sprint, the Product Owner can deny that the work represents a significant enough return on investment to warrant shipping it to production. This likely means that either the Goal was not useful, or that the Development Team did not understand the Backlog Item enough. This would mean that the Product Owner failed in their accountability to maximize value delivery.
  • At the end of the Sprint, based on either of these two outcomes, the Product Owner can choose to reject the entire Sprint and lose all of the work for that Sprint.
  • Review in the first place. It is not about acceptance or rejection of the increment by the Product Owner, but instead, it is about discovery and understanding between the Product Owner, the Development Team, and Stakeholders
• Sprint Review: Much More Than Just a Demo
  • It is the most underestimated Scrum Event
  • It is true that the Demo is an essential part of the Sprint Review, but it isn't the only one:
  • The Opportunity to Inspect and Adapt
    • Sprint is one of the 5 official Scrum Events and is an opportunity for the Scrum Team to practice empiricism
      • Inspect and review: the completed Sprint, Product Backlog, Increment, Marketplace, Budget, Timeline, Capabilities.
      • Adapt: Product Backlog, Release Plan
  • Each Sprint is an important risk mitigation tool & the Sprint Review is a decision point for the PO
  • Each Sprint can be the last one. The PO makes a formal decision regarding financing the next Sprint during the Sprint Review, 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 Increment (can be done anytime during the Sprint)
  • 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 (SR is a moment to just “accept” the ST work)
    • The Product Owner doesn't actually "own" the product, cannot optimize the ROI or make strategic decisions, Fake Product Owner (FPO)
    • The company continue to play the "contract game" with predefined scope and completion dates. the Sprint Review becomes a status meeting
    • Superficial Scrum implementation at the company.
    • The PO doesn't collaborate enough with stakeholders
    • “fake Scrum”, the ST handles only part of the system: inputs & outputs, not the real product
  • Good Sprint Review Practices
    • informal gathering
    • PB updated after/during the Sprint Review
    • often attended by the end users
    • DT communicates directly with end users and SH and gets direct feedback from them
    • "Done" product showcased on workstations where SH can play with the new functionality
  • Signs of An Unhealthy Sprint Review
    • A formal/status meeting
    • new functionality demonstrated only in a slide show
    • The PO "accepts" the work completed by the DT, SH "accept" the work from the PO
    • The DT isn't (fully) present, neither are SH and/or end users.
    • The demonstrated functionality does not meet the DoD
    • The PB is not updated. The Scrum Team works with a predefined scope
• Myth: The Sprint Review is a Demo
  • the myth that the Sprint Review is primarily an opportunity to ‘demo’ the increment to stakeholders
  • telltale signs
    • Stakeholders are easily distinguishable from the Development Team
    • Sprint Review is a Powerpoint with screenshots of (supposedly) working software
    • None of the stakeholders present are actually using, or going to use, the product
    • hardly any input from stakeholders (or they’re not invited to)
    • keyboard and mouse never reaches stakeholders/users
    • general air of nervousness in the Development Team
    • applause after the demonstration completes
    • The Sprint Review is actually called a ‘Demo’ by the Scrum Team and stakeholders
  • By treating the Sprint Review primarily as a demo, the purpose of this crucial opportunity for inspection and adaptation is lost
  • Too many Scrum Teams approach the Sprint Review as their moment
    • to show progress
    • to give a ‘product update’
    • to sell what was built to stakeholders
    • to talk about what they did
  • The Purpose of the Sprint Review
  • The Sprint Review is about
  • Optimally, has the following characteristics
  • TIPS