The Sprint Demo should be the most exciting meeting on any team’s calendar. Why? Because it is the team’s chance to showcase and celebrate all the hard work they accomplished over the course of a sprint.
Traditionally, the Sprint Demo happens at the end of each sprint with the development team, scrum master and product owner, plus anyone who would be interested in the team’s progress, such as customers and stakeholders.
During the Sprint Demo, the team demonstrates what they built- typically working, usable software- to get feedback on what they have built so far, demonstrate progress of the build, and gain insight into how they will continue their work in the next sprint based on input, feedback and questions from the meeting.
Keep in mind, the Sprint Demo agenda should not include accepting unfinished work. This meeting it to demo completed and accepted work which meets the acceptance criteria and definition of done. This is not a time when work should be accepted because it happens at the end of the sprint, any work that isn’t ready to be accepted will risk being carried over into the next sprint.
Demos should be kept informal and involve minimal preparation, no fancy sprint demo deck needed here. However, cookies and other snacks are encouraged.
Summary
Who
- Development team, scrum master and product owner
- Anyone who would be interested in the team’s progress, such as customers and stakeholders
What
- Demonstrate completed work delivered in sprint
Where
- Wherever your team normally meets – virtual or otherwise
When
- The end of the sprint
Why
- Solicit sprint demo feedback from team, product owner, customers and stakeholders
- Update product backlog/plan as needed based on feedback
- Continued collaboration with customer/stakeholder to understand needs of user
What if your team has nothing to demo?
Traditionally, Agile teams are formed to ensure that a team can deliver workable, usable software at the end of each sprint. If you’re on a team that isn’t quite at the maturity level where they are producing workable software each sprint, you might consider a sprint “check-in” or soft demo for your customers and stakeholders. If a sprint demo doesn’t seem to fit with the workflow of the team because the team’s objective isn’t producing working software, maybe there is another way the team can still showcase their work and get feedback from anyone interested in the progress of the work they are doing.
At the end of the day, Agile isn’t a one size fits all. The most important thing to keep in mind are the four key Agile Values from The Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
What works best for you during Sprint Demos? Let us know in the comments below!