Scrum Rituals: Sprint Demo

Share this article

Scrum Rituals: Sprint Demo
scrumthumb

The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.

At the end of the sprint, everything that was worked on for the current sprint is demonstrated for the team, the product owner, and anybody who’s invited to observe. This ritual is called the sprint demo, and it gives all of the engineers the opportunity to demonstrate the stories they’ve been working on that they consider complete. The sprint demo is the product owner’s opportunity to test each story, see if it meets the acceptance criteria, and then either accept or reject it.

ch4-02

The objective of the sprint demo is to get a clear picture of how much work has been completed during the sprint, and to see what the current state of the product will be after integrating the work that was done during the sprint. Based on the stories that get accepted, the team learns more about how many points they can sustainably accomplish in a single sprint, and this improves their ability to estimate stories and sprint backlogs going forward.

Note: Guests in Sprint Demos

The sprint demo is often a popular ritual for guests, because it’s the opportunity for people outside the scrum team to see what the team has been working on, and observe the state of the product in its next iteration based on the latest work produced. But the presence of guests shouldn’t be allowed to interfere with the objectives of the ritual, or alter the time box. Guests are observers, not participants. Unless feedback is solicited from guests, they should be asked not to comment on the product or the process.

Time Box

The time allocated for sprint planning is contingent on the number of stories completed during the sprint, and the level of intricacy associated with the acceptance criteria. Most teams allocate half a day for the sprint demo if they’re using a two-week sprint. Once the team has decided how long they want to devote to the demo, the scrum master should be responsible for making sure that everything that needs to happen fits within that time box.

Note: Scheduling Demos and Retrospectives Together

Frequently teams will schedule a sprint retrospective (which we’ll be covering shortly) on the same day as a demo. The advantage of scheduling these two rituals on the same day is that the interruption in productivity associated with the rituals is minimized. The disadvantage for the team is that these days produce primarily scrum artifacts, as opposed to tangible product development. That tradeoff needs to be considered, and different teams will have different preferences.

Preparation

The sprint demo is the opportunity for the team to show off all of the work they’ve been doing, and demonstrate that all of the stories they’ve been working on are done and ready to include in the product (assuming they haven’t been already). The demo covers all the work back to the beginning of the sprint that has taken a story to the team’s definition of done, whether or not that work has been released. Each person who has worked on any stories that are ready to demo needs to be prepared to explain what they did with those stories.

Often the engineers will get together with the product owner before the demo to make sure everybody is aware of what’s going to be presented. This can be a useful last step before the demo, because it ensures the stories presented meet all of the acceptance criteria. It also reminds the engineers to make any preparations necessary to allow unreleased stories to be demonstrated.

The scrum master should meet with all engineers who have stories completed, to make sure these stories are prepared for the demo. It’s the responsibility of the scrum master to run the ritual, and see to it that everything that needs to be demonstrated can be presented within the time box allocated. The scrum master’s agenda for the ritual should include a list of all the stories to be demonstrated, as well as the people responsible for each of the stories.

Tip: Let the Product Owner Drive the Demo

While some teams let the engineers demonstrate the stories, a good practice is to have the product owner participate, testing the product live. The engineer who was developing a new feature knows the happy path for the code that will always work. But a product owner will be looking for edge cases, and is aware of the acceptance criteria that are most important. Having the engineer set up the demo, and the product owner present, keeps everybody engaged and ensures that the stories are done to the satisfaction of the product owner.

Demonstrating a Story

The process of demonstrating each story should be consistent. The scrum master should go through each story on the list, and have the engineers set up the demo for the team. Many teams choose to do this using a projector in a conference room, although it’s possible to do this by gathering around a large monitor, or even through remote conferencing services, depending on the nature of the story and the preferences of the team.

At this point in the sprint, the description of the story will be familiar to most of the people in the room, but the product owner should read the story—as well as any major acceptance criteria—to the team while the demo is being set up. That way, everybody will know what to look for, and will be aware of issues that might come up.

Once the story is set up and ready to demo, the state of the product is the main focus of attention. Each story should be a complete slice of functionality added to the product, and the demo should show that slice of functionality in context with the actual product. The demo should walk through each of the acceptance criteria, proving that they have been met.

Sometimes during a demo, it’s realized that the acceptance criteria as they were originally written were inadequate, and may not have covered all the cases the product owner needed addressed. If this happens, keep in mind that a demo that meets all of the acceptance criteria—as they were specified in a story that was estimated at the sprint planning—should be considered accepted and done. Any further changes that may be needed are new stories. The product owner in this situation should be prepared to create new stories for a future sprint that relate to the additional acceptance criteria that weren’t addressed in the original story.

Warning: Don’t Go Into Detail About Issues Encountered

While it may be tempting and valuable for the engineers who worked on a story to go into detail about the difficulties or new learnings that came out of developing a particular story, the demo isn’t the time for this. If the conversation turns to those topics, the scrum master should encourage people to make a note of these points, and bring them up at the retrospective. Otherwise, the demo can turn into a long dialogue about the details of creating each story, rather than a demonstration of the product with the new stories in place.

Tallying up the Points

At the end of the demo, a number of stories will have been accepted, and some may have been rejected. The scrum master should add up the number of points completed during the sprint, based solely on the estimated points assigned to stories that were accepted as done. Only stories that were accepted as done, and that were assigned points at the sprint planning, should be included in this total. The total number of points completed in the sprint should be recorded as the team’s velocity for that sprint.

Some stories may have been rejected, or may not have been ready to demo despite being included in the sprint backlog. It’ll be up to the product owner whether stories that weren’t completed will be added to the next sprint, or put on hold pending a possible future sprint. The scrum master needs to keep track of all the stories, both completed and not yet completed, and update their status in any tracking tools that the team may be using.

Often the scrum master will generate a set of reports that are sent out at the end of the sprint demo, updating interested parties about the status of the product. If the team has decided to have both the sprint demo and the sprint retrospective on the same day, the scrum master may want to arrange the schedule so that the necessary data for these reports can be collected between the two rituals, thus making them available for reference.

Releasing the Stories

Releasing is the process that takes completed features and integrates them into the live product, either so the users can have access to them immediately, or so they can be evaluated for inclusion in a future release. The process may be overseen by release engineers, or integrated at the developer level with a set of fail-safes and rollback procedures.

Web and mobile teams have many options when it comes to releasing. For some teams, releasing a story to the customer as soon as it’s completed—sometimes several times in a single day—makes perfect sense. For others, the release process is more complicated, and it makes more sense to group stories from a whole sprint, or even multiple sprints, and do larger unified releases.

Continuous integration is an approach that supports releasing stories as they’re completed, rather than waiting for the end of the sprint. This usually depends on a robust test suite and an orchestrated set of release scripts. For teams doing continuous integration, the release of the stories into the live product will already have been done as part of completion of the stories themselves, and no further steps will be needed after the demo.

Note: Using Continuous Integration

When a team has chosen to do continuous integration, it’s important that the engineers working on a story not abandon that story until it has been released, and demonstrated not to introduce any problems in the live product. While this can result in some downtime for engineers, that time can sometimes be applied to stories related to maintaining and improving the code base.

For teams not doing continuous integration, there will be another task needed to release all the stories from the sprint into production. The tasks associated with the release process are usually considered part of the definition of done for a story, but in this case they may need to be completed after the demo.

Some teams regularly schedule releases at the start of each sprint. Others do releases more frequently, or may release only at certain times of the year, or on a schedule to coordinate with certain events related to the needs of the larger organization or the marketplace. Figuring out how to plan and schedule releases is an opportunity for the team to reflect and iterate on their process, finding the rhythm that works best for them and best meets the objectives of the product owner.

Note: Working to a Release Schedule

Regardless of the actual release schedule, it’s important for everyone on the team to understand that what will be released is only what has been completed. Scrum isn’t about rushing to finish specific stories in order to meet a predetermined timeline. Scrum is about working at a sustainable pace, learning what the team is capable of, and releasing what has been completed when it’s ready.

Any effort to stuff new stories into a particular sprint in order to meet a release schedule should be resisted by the team. If the dates cannot be adjusted, the product owner should be prepared to compromise, deciding what features need to be left out of a scheduled release in order to make time for the team to complete the most critical features.

Frequently Asked Questions (FAQs) about Scrum Rituals: Sprint Demo

What is the main purpose of a Sprint Demo in Scrum?

The primary purpose of a Sprint Demo, also known as a Sprint Review, is to showcase the work completed during the sprint to the stakeholders. It’s an opportunity for the Scrum team to demonstrate the functionality of the product increment developed during the sprint. This meeting allows for feedback and adjustments to the product backlog, ensuring that the product is evolving in a way that meets the customer’s needs and expectations.

Who should attend a Sprint Demo?

A Sprint Demo should ideally include all members of the Scrum team – the Product Owner, the Scrum Master, and the Development Team. Additionally, key stakeholders, such as clients, management, and other interested parties, should also be invited to provide feedback and suggestions.

How long should a Sprint Demo last?

The duration of a Sprint Demo can vary depending on the length of the sprint and the amount of work completed. However, as a general rule, it should not exceed the timebox of four hours for a one-month Sprint. For shorter sprints, the event is usually shorter.

How should a Sprint Demo be structured?

A Sprint Demo typically begins with the Product Owner explaining what Product Backlog items have been “Done” and what has not been “Done”. Following this, the Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved. The Development Team then demonstrates the work that it has “Done” and answers questions about the Increment.

What is the difference between a Sprint Demo and a Sprint Retrospective?

While both are important Scrum ceremonies, a Sprint Demo and a Sprint Retrospective serve different purposes. A Sprint Demo is a meeting where the team presents the work completed during the sprint to stakeholders. On the other hand, a Sprint Retrospective is an internal meeting for the Scrum team to reflect on the past sprint and identify areas for improvement in the next sprint.

How can a Sprint Demo be made more effective?

To make a Sprint Demo more effective, it’s important to focus on the product increment and its value, rather than the individual tasks completed. The team should be prepared to demonstrate the functionality of the product and answer any questions. Additionally, inviting the right stakeholders and encouraging their feedback can greatly enhance the effectiveness of the demo.

What should not be included in a Sprint Demo?

A Sprint Demo should not include unfinished work or features that are not yet functional. It’s also not the appropriate time to delve into technical details or problems encountered during the sprint. The focus should be on demonstrating the completed work and its value to the customer.

How is feedback handled in a Sprint Demo?

Feedback during a Sprint Demo is typically collected from the stakeholders present at the meeting. This feedback can be used to adjust the product backlog and guide future work. It’s important for the Scrum team to listen to this feedback, discuss it, and decide how to incorporate it into their future work.

Can a Sprint Demo be skipped?

While it’s technically possible to skip a Sprint Demo, it’s not recommended. The Sprint Demo is a crucial opportunity for the Scrum team to showcase their work, gather feedback, and adjust their plans for the next sprint. Skipping this meeting can lead to miscommunication and missed opportunities for improvement.

What happens after a Sprint Demo?

After a Sprint Demo, the Scrum team typically holds a Sprint Retrospective to reflect on the sprint and identify areas for improvement. The feedback collected during the Sprint Demo can also be used to update the product backlog and plan for the next sprint.

M. David GreenM. David Green
View Author

I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

Agilebook excerptproject managementscrum
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week