The review session in a Scrum project is a place where both the team and the stakeholders come together to assess the current state of the project and to figure out what is left to do. On the one hand, this is important for stakeholders to get in touch with their investment. On the other hand, it is equally important for identifying possible problems or opportunities.

Most sessions I saw tend to go like this. The Scrum Master starts the session by enumerating the stories in the backlog. He takes the first story, and the concerned developers start to demonstrate the progress. They explain the story, and this explanation typically boils down to saying that the story requested that if "you click here, you should get that." Then they start the program, get to the point relevant for the story, and say "you click here, you get that." Everyone is happy, and the next developers take the stage to demonstrate the next story. And so it repeats until all stories are done.

This approach limits the review to facts stating. "You click here, you get that" is just a fact, and facts are never exciting. Facts get exciting when they are surrounded by a story that is relevant for the current context.

It is for this reason that many review sessions fail to incite the audience, and as a consequence, they generate little feedback. Often stakeholders have to switch from their typical activities to participate in this meeting. They might remember little from the last review they visited, and as a consequence they feel rather remote when someone is showing some details inside the product. They need context to get involved. It’s in everyone’s interest for stakeholders to bring their energy and generate feedback.

To turn the problem around, go beyond the click. Tell them a story for why the story is important. Build a little tension. Make them want it. Then give it to them. Something as simple as "In our context, it would be beneficial to get that. Would it not be great if we could just click here, and we would get that?" can do miracles with the energy in the room.

This exercise goes hand in hand with the ideas behind impact mapping. The more you emphasize the big picture and how it reflects in the actual software solution, the more everyone’s understanding is aligned, and the more chances you get to uncover traps or opportunities.

Storytelling is a skill that can be built over time. You just have to want it.