TL;DR: The better the sprint planning, the better the demo that follows.
User Story
As a product manager, it would be awesome if people didn’t fall asleep during sprint demos.
Description
When was the last time you spotted someone in your organization energetically skipping and hopping their way through the office singing “Whoo Hoo, it’s time for the Sprint Review!”?
I know this pink-dancing unicorns scenario may seem unattainable … but it doesn’t have to be that way.
First step might be to forgo various acts of bloggery that offer formulaic cures for sprint demos in the same way one might spell out a recipe for baba ganoush to address the common cold.
Instead, I’d suggest taking into consideration what type of review you want. That is, do we simply want a visual validation of work claimed on tickets — or — do we demonstrate and discuss the value of the features completed?
If you’re like me and lean towards the latter, then you might also agree that the good product reviews are a result of even better sprint planning.
UATs
So how do we ensure an awesome sprint review through better planning? Glad you asked.
Below is a lean-like hypothesis on how to deliver a completed features demo that won’t put your participants asleep:
- We believe that sprint demos are only as good as the strategic planning that goes behind them.
- If we can ensure our backlog’s stories are written and prioritized to paint a clear picture as to ‘who’, ‘why’, and ‘what’, then the team is better equipped to plan the tactics and activities that make up the ‘what’, ‘how’, ‘when’, and ‘where.’
- We will know if we’re right if the team successfully demos completed features that are of value to the internal and external stakeholders;
— and/or —
If team members can elucidate on discoveries made during learning opportunities our more waterfall-impaired friends might otherwise classify as failures;
— and/or —
If people in the room realize that our underlying product strategy sucks.
Discussion
You may have noticed I mentioned ‘what’ twice in the second bullet point. I personally do not believe that JIRA is the infallible word of Scrum. Only a rookie PM would miss the fact that as a team grows in understanding of the product, they too grow in its ownership.
You may also have observed that I don’t really offer specific prescriptions for sprint demos, such as who are chickens and who are pigs, whether to PowerPoint or not, nor do I give a fig about who presents what.
So long as ‘what’ was done is provided in the context of ‘why’, then I suspect everyone will have a better chance to determine if there’s enough value in the delivered feature — or the product strategy it addresses — to move forward, double down, or pivot away from it.
At least that’s my theory, and I’m sticking with it until the data proves otherwise.
YMMV