The scrum methodology provides many benefits to development teams. It improves team velocity, shipping new features to customers more quickly. And it reduces developer stress, enabling developers to do better work. But it also comes with some ceremonies that can seem a bit opaque. Many teams miss out on the value of these ceremonies and consider them nothing more than bothersome meetings.
Over 85% of software developers are using agile software development methodologies (source: Stack Overflow’s annual Developer Survey) but one of the most commonly ignored ceremonies is the sprint demo. It's understandable that teams sideline sprint demos. After all, a full development sprint is usually packed to the gills with things to do. And if you're not doing a good job with your sprint demos, it's easy to miss the value they bring. In this post, we're going to talk about the purpose that sprint demos serve to a team as part of a sprint review and how you can make sure yours provide value to your team and your business.
What Is a Sprint Demo?
In a traditional scrum method, the sprint demo comes at the end of a sprint. At the start of an agile sprint, a team commits to a certain amount of work. That work is based on input from the project's stakeholders and ideally is the most important work the team could be doing for that sprint. Sprints vary in length. Some are two weeks. Other teams choose one week, and I've even seen a few that went as long as a month.
The important thing to understand is that a sprint is a well-defined block of time with a well-defined work commitment attached. Once the team agrees with project stakeholders on the work to be completed, they bear down and write code. Ideally, by the time the end of the sprint arrives, the team has finished all the work. Many teams aren't able to complete all their agreed-upon work in every sprint, but that's the target each team should aim for.
A sprint demo is your team's chance to show off to the business stakeholders. The work that they've done is important, and you want to share it with the people who are most excited about it. The best sprint demos are celebrations. Stakeholders and developers alike are coming together to share in the work they've accomplished. The team demonstrates fixed bugs, new features, and infrastructure necessary for future work.
How Should You Conduct a Sprint Demo?
The best demos are performed by the team as a whole. Some teams will identify a person who actually performs the software demonstration, but this isn't ideal. When sprint demos are at their best, they're a collaborative event where both developers and stakeholders talk about the new software.
A developer starts by demonstrating some new feature that they've completed during the sprint. They're the ones who worked on that software; they know how it works the best. Additionally, this is a chance for a developer to show off what they've done. Then, once a developer has provided a quick walk-through of all the user-facing parts of their work, stakeholders ask questions. These questions are an opportunity for stakeholders to identify the next development steps for the project. Successful scrum teams develop software iteratively, building on previous work little by little and constantly improving.
This is why sprint demos are so valuable. They're not just opportunities for the team to show off their work or prove that they're actually doing something all day. Instead, holding a sprint demo is a chance for developers and stakeholders to be in conversation with one another about new code. The goal of both the scrum team and the stakeholders is to build the best software they can. This conversation about new features helps to spark ideas from the stakeholders about what the next step should be. Those new ideas about the software feed back into the scrum process. Each sprint builds on the last, and the software continues getting better.
The Ceremony's Natural Progression
Once the conversation around a feature or bug fix finishes, the team moves on to the next item. The next developer takes over and presents the changes that they've finished. Each developer shows off their work, answers any questions the stakeholders have, then cedes the floor to the next developer on the team. It's important to note that sprint demos aren't something the team should timebox. Sprint demos take up variable amounts of time.
Sometimes, your team will show off all their work, and nobody will have any questions. The entire process will wrap up in half an hour. Other times, the team sparks terrific conversation. The meeting might take an hour or more. What's important to remember is that the meeting's value isn't in the demonstration. It's in the conversation that demonstration sparks. If stakeholders have questions about a new feature, embrace that opportunity. Answering those questions is the real value of the sprint demo.
Why Do Teams Skip Sprint Demos?
Many agile teams either skip or only sparingly provide demos for their stakeholders. There are lots of reasons this might be the case. Perhaps the most common is that most developers aren't very good at giving demos of their software. Demonstrating a software feature is a skill, and many teams don't ask developers to hone that skill. That doesn't mean that they can't get better at it; it just means that they don't exercise those muscles.
Another common issue is that sprint demos can be quite clunky. This is especially true for remote teams. Video conferencing software like Zoom or Microsoft Teams only allow users to focus on one shared screen at a time. It's common for developers to check out of the meeting mentally while they wait for their turn to present. The same can be true for stakeholders. They don't pay attention to the meeting until the feature they're interested in pops up on the screen.
In between, the team needs to go through some rigmarole. Each time a new developer comes on-screen, they need to negotiate screen sharing permissions with whomever the software thinks runs the meeting. Since only one person can share at a time, each switch is an interruption of the meeting's flow. Each interruption risks losing the people you want to be focused on the meeting. It is also hard for reviewers to comprehend a feature or describe their input when they aren’t directly able to interact with what is being demonstrated.
Getting the Most Value From Sprint Demos for Your Team
Clearly, the key to an effective sprint demo is to keep things moving and keep people engaged. Some of this means having your developers hone their skills at presenting demos. They need to be engaging and concise, and they should have their work prepared ahead of time. It's quite frustrating watching a developer fumble around with a development environment while they're meant to be showing off their work. Then, they point out the new features and open the door for questions. Like we've noted, those questions are the lifeblood of the sprint demo meeting. If you're using videoconferencing software that only lets one participant share at a time, make sure each participant is ready to go when it's their turn.
Next-Level Collaborative Sprint Demos
To this point, none of the demonstrations we've talked about are interactive. A single developer (or worse, a team representative) shows off their work. Stakeholders can ask questions about the feature, and a developer can listen to their input and show off something adjacent. But those stakeholders don't have the ability to interact with the software themselves.
Sometimes, this is the sort of thing that can be alleviated with a QA or user acceptance environment, where a stakeholder can tinker with the code while the developer demonstrates. But this kind of tinkering disrupts the flow of the meeting too. If the stakeholder discovers something they want to ask the developer about, the developer needs to switch who shares their screen. Or the stakeholder needs to provide step-by-step instructions to reproduce their current state. These conversations are valuable, but you want them to happen as quickly as possible!
This is where a tool like CoScreen can prove invaluable. Instead of sharing an entire screen over video, each stakeholder and developer in the meeting can share one or multiple application windows that present their latest achievements, like code snippets, API calls or frontend prototypes.
If a stakeholder wants to show a developer an issue that they've identified, they can pop into the developer's shared window and drive the code wherever it needs to go to demonstrate what they're talking about. There's no need to negotiate a new driver for the session. The switchover is instantaneous. What's more, the shared code can still be running right on the developer's machine; it doesn't need to deploy to a shared environment. The stakeholder can identify a bug, and the developer has the capability to try out a fix right there, while the team watches. All this happens seamlessly, during the meeting.
Sprint Demos Are the Bridge From One Sprint to the Next
Effective sprint demos are a core part of every successful agile team's process. They provide a chance for the team to celebrate their accomplishments and get feedback about their work. They also spur critical conversation that provides the spark for future sprint work.
Sprint demos are the most effective when they're a collaborative, electric environment, and they lose value when they bog down in technical and procedural challenges. When you're performing a sprint demo, you should aim to move quickly from one story to the next while providing as much time as necessary for stakeholders to converse and ask questions about the work you finished. That's where the best collaboration happens, and it's what makes the sprint demo such a key part of the scrum process.
This post was written by Eric Boersma. Eric is a software developer and development manager who's done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he's learned along the way, and he enjoys listening to and learning from others as well.
