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.
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.
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.
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.
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.