Stage Gates Meet the Sprint Review

Scrum is built on empirical process control, so gates are workable only if they inspect real evidence and leave room to adapt. A fixed full-scope commitment at G2 removes that room.

• Scrum assumes complex work where cause and effect are only clear in hindsight. Control therefore comes from transparency, inspection and adaptation: a visible Product Backlog and Increment, a Sprint Review that inspects the outcome, and a Retrospective that adapts the process.
• A requirements baseline plus a change board is a defined-process model: it assumes the requirements can be known up front and that conformance to them is the measure of success. For a claims portal this is exactly the assumption that will fail.
• Gates themselves are not forbidden. A gate that inspects the working Increment, the Definition of Done, and the forecast range is a legitimate inspection point, and can force useful decisions about investment.
• What is incompatible is committing to full scope and a fixed date 12 months out at G2. That converts forecasts into promises, makes the Sprint Review a compliance check rather than a feedback loop, and removes the organization's ability to change its mind when it learns something.

The practical position: keep the gates, change what they inspect. At G2 the team can present a forecast range, the evidence behind it, and the options (scope, date, investment). The Product Owner should not sign a fixed scope and date that the Developers have not forecast and cannot control.

Offer Done work against a forecast range: burn-up of Increment that meets the Definition of Done, plus the Sprint Review.

Why percentage complete misleads:

• It is usually computed from hours spent or from requirements signed off, neither of which says whether anything works. A task can be '90% complete' for weeks.
• It is not binary. Scrum treats work as Done or not Done according to the Definition of Done; a percentage invites optimism and hides rework and integration risk.
• It measures conformance to the baseline, not whether the product solves the claims team's problem, so it cannot detect that the baseline itself is wrong.
• It gives a false sense of precision, which is exactly what the change board used to reject a working slice over two missing fields.

What to offer instead:

• A burn-up chart of Done backlog items against the forecast range, updated at every Sprint Review, with the assumptions stated.
• The Increment itself, demonstrated at the Sprint Review, so the PMO inspects working software rather than a status table.
• Continued Gantt-style reporting if the PMO needs the format, but labelled honestly as a forecast against the current Product Backlog, with a clear note that scope and date will be re-forecast each Sprint.

Note the structural impediment: the change board rejecting a working slice over two fields is a delay in the system. It belongs on the impediment list and in the Retrospective, and it should be escalated with data, because the team cannot fix it alone.

Work by influence and evidence, not by declaring the PMO obsolete. The Scrum Master serves the team and the organization.

First 30 days:

• Make sure the basics are real: a Product Owner who orders one backlog, a Sprint Goal per Sprint, a Definition of Done the team has actually agreed, and a Sprint Review that shows a working Increment.
• Coach the Product Owner to negotiate at G2 with a forecast range and options, rather than signing a fixed scope and date under pressure.
• Get the PMO and the claims stakeholders into the Sprint Review so they inspect the Increment. The rejected working slice is the strongest argument available.

Days 30 to 60:

• Make the organizational impediments visible with data: change board turnaround time, gate criteria that ignore the Increment, reporting that rewards percentage complete. Raise them through the Retrospective and then with management.
• Teach the team to say what it can forecast rather than what it can promise, and protect the Sprint from mid-Sprint scope changes.

Days 60 to 90:

• Agree a small set of success measures with management for the pilot, review them, and be explicit about where the organization's rules still conflict with Scrum rather than hiding it.
• Coach the Developers toward self-management and cross-functionality, and keep the Retrospective as the engine of improvement.

Avoid: a big-bang transformation, going around the PMO, or silently running 'Scrum in name only' while the defined process continues underneath.