Software teams are moving faster than ever. The products we work on are constantly changing as engineers continuously deploy code. One way software teams can keep everyone in the loop is by doing regular team-wide demo sessions, or sprint demos.
The purpose of sprint demos
Sprint demos are traditionally held at the end of the sprint. They show internal stakeholders what’s been done and how things work. They’re an opportunity to get feedback and receive questions from other team members. Teams can share insights, and begin thinking about what will go into the next sprint. Sprint demos may include a single software development team, or they may include teammates from customers support, marketing, and other non-engineering roles.
When involving cross functional roles like this, sprint demos can serve the purpose of keeping the entire company up to date on what’s going on in the product. Including the entire team on sprint demos also provides the opportunity to get feedback from a variety of roles, which can be incredibly value.
How sprint demos impact QA
Sprint demos can have a positive impact on the quality assurance of your product, whether or not you have a dedicated QA team at your company or not. A good sprint demo session involves teammates asking questions and raising concerns. These interactions can ultimate lead to improvements in the product, and sometimes a complete shift in direction on how something is being built. As someone shows their work, the rest of the room is able to consider potential risks, which can be discussed and then addressed in upcoming sprints.
Sprint demos prepare others for what’s to come
When doing team-wide demos with cross functional roles, marketing and support are able to get up to speed on what’s changing. This is a great way to bake in a handoff process with your marketing and support teams. From here, marketing and support teams can prepare content, messaging, and updates to existing documentation. Support is also now in the loop on how an upcoming change or feature will work so they can truly “support” the feature.
A good demo culture is a culture of sharing and transparency
I once worked at a company of 15 people. I was running customers support and sat 20 feet from the engineers. But I always found out about features after they were released. No one was filling me in, I wasn’t invited to daily standup, and things were just really “siloed”. The system was broken. Then, we started doing regular demos… and I was invited (perhaps because I created the meetings).
Things got better nonetheless. We were sharing information across teams. This lead to a QA role being created and embedded into the development team. These bi-weekly demos became a big part of our culture.
Preparing for sprint demos
If you’re not already doing regular demos, it’s not too late to start! Start by getting it on the calendar and asking for volunteers to show progress of what they’re working on. Book an appropriate room or space to hold the demos, and make sure to invite in any remote teammates so they’re also in the loop. Chances are, you’ll see teammates collaborating more, which will improve the overall quality of your product.