The Sprint Review That Nobody Uses

The Sprint Review is being used as a status report and a scheduling negotiation. Neither is its purpose.

Framework problems:

• The Sprint Review exists to inspect the outcome of the Sprint, discuss progress toward the Product Goal, and determine what to adapt next. Its output is an adapted Product Backlog, not a signed-off status deck.
• There is no Product Goal, so the Review has nothing to inspect progress against. That alone makes the event incoherent.
• The Scrum Master presenting completed tickets inverts the event. The Developers should show the Increment; the Product Owner should discuss value and what to do next; the Scrum Master facilitates.
• No demo because the environment is unstable is a transparency failure dressed as a logistics problem. If it cannot be demonstrated, it cannot be inspected.
• A 600-row backlog ordered by 'whatever was discussed most recently' is not an ordered backlog in any meaningful sense, and it guarantees the team builds a mix of things nobody chose.

Organisational problems:

• The Product Owner lacks decision authority; a steering group effectively orders the backlog. The PO role requires one person accountable for value, and this arrangement removes that accountability even though the title exists.
• The steering group has no legitimate forum in Scrum other than as stakeholders at the Sprint Review. Using it as an approval gate for backlog items produces the ordering chaos above.
• Nine Developers is within the recommended size but at the upper end; this is a secondary concern compared with the authority problem.

The two sets are linked: the Review cannot work while nobody in the room can make a decision.

Split by what the Scrum Master can change without permission versus what requires organisational design decisions.

Next two weeks:

• Work with the Product Owner to draft a Product Goal - one or two sentences describing a future state of the product that gives the next several Sprints a direction. Bring it to the team and to the Review for reaction. A draft that gets argued about is better than no goal.
• Restructure the next Sprint Review as a working session: invite the six to eight stakeholders who actually influence the product, keep the date negotiation out of it (handle it separately with the Product Owner), have Developers demonstrate the Increment, and end with a concrete discussion of what to do next.
• Attack the 'unstable environment'. Get a stable, demonstrable environment or find what is blocking it, and quantify the cost. Present it as an impediment with evidence.
• Run a refinement session on the top 20 backlog items with the Product Owner, ordering by value and risk, and stop treating the 600 rows as the working set.

Longer escalation:

• The Product Owner's authority. If every item above a threshold needs steering-group approval, the accountabilities do not match the title. Propose that the steering group acts as stakeholders at the Review rather than as an approval gate.
• Who owns the Product Backlog, and how the 600 items get pruned.
• Any organisational mandate that forces the current status-report format.

Justification: the Scrum Master can improve events and artefacts by working with the team and Product Owner, but cannot reassign decision rights. Attempting the second without the first produces a restructured Review that still has nothing to inspect.

Build authority through evidence and small, reversible decisions rather than demanding it be granted.

Steps:

1. Derive the Product Goal from what already exists. The compliance report, the user complaints about usability and the statutory obligations are all real inputs. Draft two or three candidate goals and test them against the question: does this help us decide what to do next? A goal that cannot reject a backlog item is decoration.
2. Create a thin, ordered top slice. Take the top 15 to 20 items, order them jointly with the team, and state the rationale for the first five in one line each. This gives the Product Owner something defensible to take to the steering group, rather than a request for blanket authority.
3. Let the Sprint Review do the political work. When stakeholders see a working Increment and are asked what to change, the discussion shifts from approving items to evaluating outcomes. The Product Owner's position strengthens because she is the person who can answer.
4. Handle the threshold rule explicitly. Ask the steering group to delegate decisions below a higher threshold to the Product Owner, with the Review as the transparency mechanism. Propose a trial period and a review of how it went. Do not frame it as removing oversight; frame it as making oversight effective.
5. Coach, do not replace. The Scrum Master must not start ordering the backlog or negotiating dates. That would confirm that the Product Owner is a figurehead and leave the underlying problem intact.

The usability complaints are useful leverage: they show that meeting Sprint commitments is not the same as delivering value, which is the argument the Product Owner needs and the Scrum Master should help her make.