Energize Your Team at Sprint Demos – Focus on Results, Not Actions

During the course of a sprint, it’s often easy to get lost in the weeds, especially when implementing a new feature. Seeing the feature in the context of the project goals is not usually top of mind.

The sprint demo is a great time to remind everyone how new features fit into the larger picture. More importantly, it’s a great time to communicate why the features are being built and how they will help accomplish the goals of the project.

When prepping the sprint demo, I’ve found a few things to focus on that help keep the team engaged and energized. Essentially, I try to sell the project to the team. While the team might know why the project is important, having a reminder every sprint can help unify the team’s vision for the future and get them excited to be on the project.

Relate Features to the Goals of the Project

Each feature, no matter the size of it, contributes to reaching the project goals. While the contribution of most features might be obvious, I try to place special emphasis on smaller features. By pointing out the value in the small tasks completed during the sprint, I can help motivate the team to continue doing their best work, even on the seemingly trivial features.

For example, if the development team did work to disable a button on the UI when an action is invalid, it can be pretty easy to gloss over. By ignoring that detail, the broader team might not get as excited about the work done in that instance. Instead, I try to frame changes, like disabling a button, as an optimization to the user’s workflow. The software is directing the user’s attention to what’s important and helps focus them on the work that’s on-screen.

Emphasize the End-User Experience

The sprint demo should present what the end users can now accomplish, rather than focusing on what changed about the software. It’s cool that the software gains some new capabilities during each sprint. However, the really exciting part is the improved workflows that a user will experience, making their lives just a bit better.

For example, my current project has a table with a lot of product data. If the team adds a new data filter, I can make the demo more interesting than simply saying, “Look! You can now filter by product line!” Instead, I can frame this new feature by discussing how the user now has an easy way to dissect a large amount of data, an action that was previously possible only through several manual steps.

Relaying these types of experiences to the stakeholders at the sprint demo can generate more excitement and make the project feel more fulfilling.

Highlight Technical Achievements

Not all technical work done during the sprint has a user interface to show off to stakeholders. However, technical work in the background still helps the project achieve its goals, so it should be presented in the demo, if possible. I’ve found it useful to clarify how the technical tasks will help achieve the long term goals of the project.

One example from past experience is demoing updated automated test tooling. The development team put quite a bit of effort into doing headless browser-based testing. Instead of running a test, I spent time explaining why the team thought it was important to add this sort of testing capability. By adding browser-based testing, the team was able to cover a gap in our test suite, namely UI interactions. This was a common source of regressions since the automated test suite didn’t necessarily cover those complex interactions. While the end-user and stakeholders might not immediately see positive benefits from this change, the development team was able to spot regressions quicker and address the regressions before releasing the new software.

Conclusions

I’ve enjoyed putting together sprint demos. It’s nice to have the opportunity to review the great work my team has done in only a few weeks. I try to convey that excitement to the broader team by focusing my content on how we are achieving project goals, creating a fantastic user experience, and excelling as a development team with improved practices.

What do you do to make sprint demos more exciting? Leave a comment; I’d love to try out more ideas.