Scrum Sprint Demo: A Comprehensive Guide

Key Takeaways: The sprint demo showcases completed sprint work, allowing the Product Owner to validate against acceptance criteria. It clarifies completed work, improves estimation, and informs the team's velocity. The focus is on demonstrable value, not technical details or problems (those belong in the retrospective). Accepted features are then integrated (released) according to a sustainable schedule.

(This section is based on Scrum: Novice to Ninja by M. David Green. Available in stores and as an ebook.)

The sprint demo, held at the sprint's conclusion, is a crucial ritual. The development team demonstrates completed work, while the Product Owner assesses completion against acceptance criteria, accepting or rejecting each story. This provides a clear picture of sprint progress and refines future estimation.

Sprint Demo Objectives:

The primary goal is to understand the sprint's output and the product's updated state post-integration. Accepted stories determine the team's velocity, improving future sprint backlog estimations.

Guests at the Sprint Demo:

While guests are welcome observers, their presence shouldn't disrupt the demo's objectives or timebox. They are observers, not participants, unless feedback is actively solicited.

Timeboxing the Sprint Demo:

Time allocation depends on the number and complexity of completed stories. A half-day is common for two-week sprints. The Scrum Master ensures adherence to the allocated time.

Combining the Demo and Retrospective:

Often, teams schedule the retrospective on the same day to minimize productivity disruption. However, this prioritizes Scrum artifacts over tangible product development – a trade-off requiring careful consideration.

Preparation for the Sprint Demo:

The demo showcases all "done" stories, regardless of release status. Each contributing team member should be prepared to explain their work. A pre-demo meeting with the Product Owner ensures alignment with acceptance criteria and prepares for demonstrations. The Scrum Master coordinates preparation and ensures the demo fits within the timebox.

Product Owner-Driven Demos:

While engineers can present, having the Product Owner conduct live testing is beneficial. Engineers know the "happy path," but the Product Owner identifies edge cases and prioritizes acceptance criteria, ensuring comprehensive testing and stakeholder engagement.

Demonstrating a Story:

The Scrum Master guides the process, systematically reviewing each story. The Product Owner reads the story and acceptance criteria while the demo is set up, ensuring everyone understands expectations. The demo focuses on the functional addition to the product, demonstrating each acceptance criterion's fulfillment. Inadequate acceptance criteria identified during the demo result in new stories for future sprints.

Avoiding Detailed Discussion of Issues:

While valuable, detailed discussions of development challenges should be deferred to the retrospective. Focusing on the product prevents the demo from becoming bogged down in technical details.

Tallying Points and Velocity:

The Scrum Master calculates the sprint's velocity based on points assigned to accepted stories. Rejected or incomplete stories are tracked and their status updated. Reports summarizing the sprint's progress are often generated.

Releasing the Stories:

Releasing integrates completed features into the live product. Release methods vary; some teams release immediately, while others group stories for larger releases. Continuous integration supports immediate release, eliminating post-demo release steps.

Continuous Integration:

With continuous integration, engineers shouldn't abandon a story until it's released and tested. This might require dedicated time for maintenance and improvement.

Release Scheduling:

Release schedules should align with the team's sustainable pace and the Product Owner's objectives, not arbitrary deadlines. Avoid rushing to meet deadlines at the expense of quality; prioritize critical features if necessary.

Frequently Asked Questions (FAQs)

(The FAQs section has been omitted for brevity, as it largely repeats information already covered in the main text.)

The above is the detailed content of Scrum Rituals: Sprint Demo. For more information, please follow other related articles on the PHP Chinese website!