The Review Sweet Spot

The Review is a very important moment for any agile team and their stakeholders. Regardless if it's a Sprint or Release review, it is the place where people invested in the work come together to inspect what has been done, and adapt the way of working an upcoming plans accordingly.

What a team brings to a Review sets the stage for the discussions that will be had, and what can be achieved during the session.

Remember that a Review is neither a status report, nor a presentation. It is an opportunity to collaborate. To get the most out of this opportunity, make sure you welcome input and ideas by adding items to the agenda that invite discussion.

Selecting what to show and discuss from the last iteration is a fine balancing act:

Not too coarse

If what you are discussing is too rough, participants will need to go through all kinds of mental gymnastics to understand which parts they can contribute to and which are so much work in progress that it's still too early. If some parts need to be imagined, it gets even harder to understand what is supposed to happen.

Not too polished

If you present something that is basically watertight, and it would take multiple hours of deep diving into the problem description and the solution to write a multi-page critique of what has been built, you will probably get a couple of nods of people thinking "well, looks like they know what they're doing." Giving feedback on something that is very complete is also difficult because of two biases at play: One is the sunk cost fallacy ("so much work already went into this, what happens if I challenge the basic idea of it?"), and the other is social desirability bias, that describes our tendency of responding in ways that feel acceptable to others. It's really difficult to give honest feedback (both positive and negative!) if you sense that already a lot of work has been put into something.

Not too small

Depending on context, but sometimes it's really hard to give feedback on a button. Or a form field validation. If you want to discuss something very small, be prepared to end up talking about really really tiny details, or something else entirely.

Not too big

If what you bring to the table is too big (too complex, too large, too difficult, too context-rich) people will struggle to understand what they are looking at.

If you find it difficult show something that is "just right", maybe try one of the following tactics to have a meaningful conversation in your Review session:

Give Context

Smaller or more obscure items can be discussed by giving more context about them

Before - After

Improvements or bugfixes are more easily understood when you can show a before/after. Also, your work will become more clear, and people will understand the solution.

Involve Earlier

Don't wait for the whole thing to be finished before you bring it to the table. Instead, show incremental progress while sticking to the Golden Rule of Reviews: Only show what is Done (with a capital 'D').

Be specific in your requests

If you feel that a discussion about the current increment and the work done in the last iteration would be too open and might not produce the results the team needs to continue, focus the conversation on the aspects you need input for.

What if there's nothing to inspect?

The Review is not a status meeting. If for some reason you cannot find something on your sprint board that hits that sweet spot, talk about that.

Talk about what is difficult, what keeps you from producing a meaningful increment, what you did this sprint to create value. Talk about impediments and how stakeholders can help you remove them. Remember one of the scrum values - Openness. It's not just "ok" to talk openly about difficulties; Being transparent with challenges the team faces is a requirement for empiricism.