The Sprint Review is my absolute favorite Scrum practice. Why? From a productivity perspective, it is the main feedback mechanism. And from a health perspective, it is the mechanism that brings love to your Agile team.
What is a Sprint Review (or Sprint Demo)? At the end of each sprint, the team demonstrates that the work promised at Sprint Planning has been completed. This gives the Product Owners a chance to say “nope that’s not what I wanted” or “that’s exactly what I wanted” before too much time has been invested.
Here are some great advantages to holding a Sprint Review, whether or not you are Agile!
Build trust with your Product Owner(s) / Customer. By creating complete transparency as the work is getting done, you will build trust with your customer. You may need to reorganize your plan so that you deliver in valuable chunks instead of building foundations and laying on top. Low-trust teams find the idea of transparency counterintuitive. I hear them say “Our customers don’t care, they just want it done.” As many times as I’ve heard that claim, it’s proven false every single time. What they find is that it creates a true partnership and the customer gains an appreciation for the work.
Let the doers shine. In large companies the people behind the scenes rarely see their work being appreciated. It brings tears to my eyes at Sprint Reviews when I see a programmer beaming as they demonstrate their work. This is where the love comes in. And appreciation doesn’t have to be in the form of kumbaya praise. I’ve seen plenty of times where a change was requested but still, the programmer appreciated the opportunity to hear the feedback and reasoning directly from the customer. Direct feedback is much more meaningful than a second-hand order passed down from management.
This brings me to another point. Delivery teams, shut up. During the Sprint Review don’t criticize your peers. Especially if you are a manager. Don’t ruin their moment. Pass along your feedback and questions later.
Delivery teams learn to accept feedback. Accepting feedback is new for teams who are used to working from a spec. It is totally valid for the Product Owner to say “yeah that’s what I asked for but now that I see it, I realize I need something totally different.” This can be a hard pill for new Agile teams to swallow. The best advice I have is for Product Owners to be really nice about it and acknowledge that their view has changed. We’re not going to work on the wrong thing just because it was on paper, we’re going to do what’s right for the company.
What if I’m not making software? What if I’m not Agile? Sprint reviews/demos will benefit anyone. Pick a cycle that’s half of what you think it should be. I say this because if you don’t shorten your feedback cycle you are doing exactly what you do today, and likely showing a finished product. You want feedback earlier than you get it now.
What do we show? Take a close look at the value your team is delivering and show that. For example, if you deliver training, you might show an outline the first week and deliver (aka teach) a completed module the next. I’ve worked with teams that design hardware. Each sprint they show the hardware with partially working features. “But we design it all and then make it”. Now’s the time to stop doing that. Make a working prototype. A marketing client of mine started reviewing drafts in priority order, weekly.
What have you done to make your Sprint Reviews effective? We’d love to hear from you!
“
Taste the Soup.
— Ray Dalio
