We’ve all been there. We show up to the sprint review, and a team is showing off technical specs, slides, or perhaps sharing their code. Rarely do they demo the increment they’ve created. And maybe they’re also not inviting anyone outside the team to be part of the conversation. As their coach, we want to ask questions but about what? The craftsmanship of their code? That’s important, but solving the user’s problem is more important. This is a dysfunctional sprint review.
I remember a team just like this. They were a brilliant group of engineers, but their approach was to talk to a limited set of stakeholders and then disappear for three to six months. On the other side, they’d provide their solution and immediately pivot into the next project. Zero transparency. Zero opportunity for user feedback or validation. Dissatisfied users.
Something wasn’t working, and they felt it. I knew preaching about the purpose of the sprint review wouldn’t help. And I don’t believe in imposing my will on teams. Instead, I asked if they wanted to try something different, and they did.
At their next few reviews, there would be no slides, code, or specs. Instead, they would demo what they created, and I’d be their test audience. I playfully told them that I was the dumbest person in the room, and if I understood, then everyone else likely did too. While a team member demo’ed, I would stand by a white board answering three questions:
- Who cares? Tell me who the users are. When we get comfortable, these are the kinds of people we’ll invite to our reviews.
- Why does it matter? Provide a few sentences of back story. What makes the thing we’re building useful? As your “who cares,” what problem does this solve for me?
- What did you do? Now that we’ve set the stage, show off what you built. Walk us through the small steps you took toward that why above.
The team had a lot of fun with this, often at my expense. Did I look like I was doing mental calculus? The team member knew to use less jargon, slow it down, and maybe dumb it down. Was I giving an impatient look? Then the team member is probably using too many words without answering one of the three questions or making a point. This is something I typically refer to as low information density.
Why use ten words when five will do?
The team liked it so much that they began inviting outsiders to their reviews. This lead to better products, better conversations, and a happier, more productive team. Maybe you’re suffering from a dysfunctional sprint review as well. If so, give it a try and let me know how it goes. And if you’re looking for metrics to judge your sprint reviews by, I have a few suggestions as well.
Finally, special thanks to Maarten Dalmijn for helping me put these thoughts to paper. Thanks much, Maarten. Our community is a little brighter because of you.
Do you want to get notified when new posts are published? Leave your email below.
