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
    • an event that “is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”
    • “The Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value”
    • “Collaboration between the ST and its stakeholders is key during the Sprint Review”
      • the problem we’re trying to solve and the optimal solution will emerge from what we learn during development
      • The SR is a critical opportunity in Scrum to make this possible by letting insights emerge from the work that was done and to build on them to inform the next steps
  • The Sprint Review is about
    • Making them Transparent (increment and PB)
    • Inspecting both (increment and PB)
    • share insights on what was learned from that inspection
    • decide together on next steps
    • OUTPUT:
      • adjustments to the Product Backlog based on what was learned
      • is about answering: “Based on what we learned this Sprint, what are the next steps?”
      • This provides valuable input for the Sprint Planning
  • Optimally, has the following characteristics
    • Stakeholders and Development Team indistinguishable
    • Participants are actively invited to offer feedback, suggestions, and ideas
    • The PB has a prominent place and is actively adjusted as new insights emerge
    • Rather than the DT presenting the Increment to the PO, is more about the entire ST (the PO included) sharing the Increment with stakeholders
    • The PO discusses the PB and communicates likely completion dates based on the progress
  • TIPS
    • Reiterate the purpose of the Sprint Review before you start
    • Development Team to pair up with stakeholders
    • Avoid Powerpoint or screenshots to inspect the state of the Increment
    • Make sure that all developers attend the Sprint Review
    • Use active formats, don’t sit around a table looking at a screen. Use facilitation techniques (like Liberating Structures) to actively engage all participants, should be a ‘feedback party’
      • Use format such as 1-2-4-ALL, Shift & Share or a carousel to break down larger groups into rotating pairs of small groups
      • Use Impromptu Networking or What, So What, Now What after inspecting the Increment to explore next steps or offer suggestions for the Product Backlog
    • Invite real users to the Sprint Review, but avoid turning it into a ‘user acceptance test’
    • Change the format. Vary the format of the Sprint Review based on context (continuously search for the best way to gather feedback from stakeholders)
    • Ask feedback about the event: As part of the closing, ask participants what can be done to (further) improve the value of the Sprint Review based on how it went
    • Invite participants, explaining why their presence is important
    • Be open and transparent about undone work