It's a review, not a demo
- Richard
- Apr 2, 2020
- 4 min read
The sprint review is the most commonly misunderstood and malpracticed ceremony. Let's take a closer look at how we can improve.
Why do we review
Let's start with asking ourselves why we do reviews. It's not a time to relax, get out of your work for a minute and eat some popcorn while watching a show. Think about agile for a second, the whole idea is focused on getting feedback and improving, and this is exactly why we are doing reviews. We are showing the audience what we've created in our sprint and the audience can give their feedback. That feedback will be discussed and the suggested improvements will be added to our product. This enables us to know whether or not we are on the right track and it allows us to modify the product in such a way the audience gets exactly what she wants.
The meeting
One common mistake lies in the ownership of the meeting. This may sound strange, but I've actually heard scrum masters tell the product owners it's their meeting, so have a blast. This is not how we envisioned the review when we thought of this ceremony. First of all, it's not a meeting with an agenda and everything. It's a team collaboration event. Every member of the team should take ownership of this meeting and prepare for it accordingly.
The audience
I've named the audience before a couple of times, but who should be in this audience? Some teams just review for themselves, which is a little awkward and can be demotivating. Sometimes they might think they're not ready yet to go public, other times they might think nobody's interested in their product. Either way, the most important members of the audience are the people you're building product for, usually the customers. And I know some companies are really big and there's no way they can have their customers in the review every two weeks because whatever reason they can think of.
First of all, stop thinking for the customer and just invite her, let her decide if she's going to be part of the review or not. It's in their best interest too, you know. Second, if the customer can't be there for whatever reason, there should be a proxy available. Someone who knows the customer and the scope well enough to give the feedback you would want. This could be the product owner, or a project manager or maybe even a coworker from support. If no proxy can be found, be flexible and reschedule the review.
Support and implementation consultants can be invited for the review, it's important they know what products are coming and how to configure and support it. You can however choose not to do so and have a separate training session with them whenever the product's finished. This usually saves more time.
The demo
I can't stress this enough, it is -not- a demo! Stop the developers from showing their product to the customer. Everything makes sense when someone else clicks on the screen, and they know exactly where to click anyway. Engage the customer and ask them to use the product instead. You'll create a setting where you can immediately see whether or not your product is intuitive enough, or what error handling you should add. You'll get much, much more essential feedback from the customer this way. How often did you demo your product to the customer, who nodded in agreement only to have them ask questions or even add feature after the release? I urge you to please let them review your product.
The value
The review is often scary to the team, and they will feel the need to show what they've done. But this feeling needs to be suppressed. We don't want to show the customer unfinished work, just to prove that we worked. We want to show the customer what value we've added to the product, in other words we want to show them finished stories. The review is not a place to see which developer did how much work, it is not a place to judge them. It is a place to improve the product, together.
The feedback
Many reviews will end up in suggestions, modified content and added features. You need to make sure you prioritise these requests with your customer, so both of you know when to work on these and what the consequences are for the rest of the project.
In a lot of cases feedback may or may not be recorded, but it is essential to take the feedback seriously. If you don't, people may stop giving feedback and you'll lose a core asset of why you're being agile.
You also need to make a point reservation, so you can actually work on the suggestions. What greater motivator is there, then to show the customer you've implemented their feedback during your next review.
Save your review
Whether it's for the archive, or for people who couldn't attend to look at it later. Record your review and make it available to anyone who wants to see. This offers some more flexibility to your audience, but more importantly it'll allow you to look back. Why is this important you ask? Because maybe, during a retrospective, you can focus on your review abilities. You can pick some older ones, and some newer ones and compare how you've grown. Is this the growth you wanted? What is a mistake you keep making? Remember, agile is about feedback and improving, and now you can improve your reviews.
Comentarios