What are sprint demos and why are they so important?
Sprint demos are ceremonies that happen at the end of each design or development sprint, and are an opportunity for the team to demonstrate progress and create alignment.
During this session, the team will walk the stake holders through what has been produced over the last sprint. This process allows for short feedback loops, ensuring that the team & the stakeholders are aligned when it comes to execution of the brief and that all expectations have been met. This is often followed by a discussion regarding any future iterations which are required for the feature/s as well as a chance to discuss upcoming priorities that need clarification. I have found these to be a fundamental part of the sprint process for several reasons:
- They show real tangible value. Stakeholders put a lot of faith in us to deliver the goods and this is the opportunity to show them those goods.
- They ensure alignment between stakeholders and the team.
- They increases the number of feedback loops : No more waiting for stakeholders to review UAT (User Acceptance Tests) – quick and interactive feedback!
Who should be in the meeting?
Everyone that matters. We have found it extremely valuable to have our developers / designers in all sprint demos. As we know, this is imperative when it comes to discussing and deciding on the more technical aspects of a project, but it also aids with the day to day discussions. It fosters the relationship between both developer and stakeholder while building trust and accountability.
I highly recommend keeping the meeting size to 2-3 key stakeholders and decision makers as well as the dev / design team.
Who actually runs the demo?
Project Managers or Product Owners should facilitate the entire process, but who actually demos the work is up to your discretion. There are three different approaches to running the demo:
- Project Manager / Product Owner demos the team’s work.
- Each week a member of the development team take a turn to demo the whole team’s work.
- Each developer demo’s their own work.
- The stakeholder runs through the features developed themselves and asks the team questions as they go
I personally prefer having the developers demo their own work. It creates a sense of accountability and also allows them to field any specific questions about the functionality that might arise during the demo process.
What happens in a sprint demo?
- The agenda is sent out the day before with tasks completed and tasks to be demoed.
- The first thing we do is recap what has been completed in the previous sprint / week and communicate any issues or blockers we may have encountered.
- Each developer will demo the work they completed. Just because it isn’t UI work doesn’t mean it can’t be demoed! Sure, our aim is to always show value, but value isn’t always in pretty screens.
- Discuss and confirm upcoming priority based on the features demoed. Ideally this should be discussed in the week prior, so that you have a general idea of what’s next and can incorporate this into your backlog refinement.
- Open the floor for any questions.
What about the frequency of sprint demos?
Even though we work in two week sprints for both dev and design, I find that design projects are better served by a higher frequency of Sprint demos. At Nona, most design sprint demos happen on a weekly basis and not only at the end of the sprint.
Official development sprint demos take place at the end of each sprint (generally the last day of the sprint prior to the next planning.) This allows the team enough time to ensure that they can wrap up any lingering tasks so that we have a successful demo, while also allowing us to bring any iterations into the new sprint.
We often also have unofficial demos, where we demo individual features to individual stakeholders, throughout the sprint. However, these features will still be demoed in our official sprint demo so that we have complete alignment across the team and all stakeholders.
How long should these meetings be ?
This very much depends on your team size and the velocity achieved in a sprint. The majority of my demos and prioritisation meetings are 60 minutes long, however I generally book a 90 minute slot in case there need to be additional conversations.
As much as I like to timebox meetings, some conversations need to be had. The more comfortable you get with a project, you will notice that demos start becoming more and more efficient, and we often get through ours within 45 minutes.
In a nutshell, demos are a critical part of the agile process, and a great opportunity to share the value you have been producing over the previous sprint. GET DEMO-ING!