What to do in a Review?

The Review meeting is the Inspect+Adapt ceremony of the Product. It is intended to align customers and developers. Sometimes, teams are confused as to what to do in a Review to reach this goal.

What you need

A good Review creates transparency on many levels. Mutual understanding is improved on many levels:

• Customers learn what the product looks like right now
• The product owner learns what customers need next.
• Developers learn what customers care for - and what they don't.
• There is healthy discussion about why developers chose specific design approaches

The best Reviews end with all attendants being aligned on what will happen next.
If stakeholders are satisfied, the next steps are clear to the Product Owner and the developers.
If stakeholders are dissatisfied, corrective actions are identified for prioritization and the next planning.

Maximize feedback

The Agile Manifesto states that "Working Software is the primary measure of progress". Developers should never feel pressured to justify that they were "busy". We don't need to prove or justify anything - we need feedback.
Any element of the Review that is not aimed at obtaining feedback is waste. When preparing a Review, the most important questions should be "Which feedback will we get from this?" and "Why would we need that feedback?"

Bad practices

The SAFe 4.0 Scrum Master Orientation suggests that in a Review, in SAFe called "Team Demo", the team should do the following:

Teams demonstrate every Story, spike, refactor, and NFR 

Now, this is actually a terrible idea for Reviews. The topic has been discussed on LinkedIn.
Let's discuss why this is a bad idea, point by point:

Bad idea #1: Team doing it
When you really want to know how the customer/stakeholder feels, they should be in the driver's seat. From an involvement perspective, the stakeholders should be  as active as possible during the Review. This maximizes the amount of feedback and learning the team will receive.

It's ok if the team explains what to look for, it's a bit troublesome of the team has to walk the stakeholders through.


Bad idea #2: Demonstration
Real learning and the interesting discussions happen when someone other than the developers (who know exactly how they built it) have to figure out how to use the new feature. Many quirks remain hidden until a first-time user tries out the product.

Let the customer/stakeholder play with the application.


Bad idea #3: Review Stories
Stories are explanations of the customer's needs. The team should not demonstrate what work they have done to fulfill the customer's needs. Much more interesting is the real change to the product and the impact it has on the customer.

Move from stories towards customer centered goals.


Bad idea #4: Review Spikes
Spikes are backlog items intended solely for the team's internal learning. While the team may use spikes to discover what the customer really wants or how to serve the customer need, they do not result in Working Software.

Without categorically denying that spikes should be demonstrated, a spike is only interesting if the developers need a specific decision from the stakeholders based on that learning.


Bad idea #5: Refactoring
The purpose of refactoring is "provide the means to integrate a new feature". Refactoring is a "semantic-preserving transition". This means that from a user perspective, refactoring makes no difference. On the one hand, refactoring is hygiene work that "just needs to be done". On the other hand, refactoring generates no learning opportunity.

Keep refactoring work out of the Review.

Bad idea #6: NFR's
Non-functional requirements are, by their very nature, not functionality. Their impact is often hidden from a user perspective. While it is possible to demonstrate (best with real examples rather than some static images/slides) NFR's, this returns to the question: "What learning do you expect to come out of presenting that to the stakeholders?"

NFR's are only relevant if more learning is expected from the Review.

Summary

Reviews are fairly simple.
The team should be offering stakeholders an opportunity to inspect the team's attained goals and provide feedback.
The format of a Review should maximize activity, interaction and discussion of all those involved. If everyone can learn something from the Review, it is valuable.
The core question for every Review would be "How can we maximize learning something about the product?"

Make your Review a valuable learning opportunity.