The teams are delivering at their normal pace. Sprints close on schedule, velocity is steady, and the due date is still three months out, so the steering report is green.
But the work underneath that date no longer fits inside it. The features have been broken down and the epics estimated, and the sum of them now lands in April rather than January.
The delivery target hasn't slipped. The work just outgrown the original planned delivery.
Why the report stays green
Most status reporting asks a narrow question: has the date changed? If nobody has edited the due date, the answer is no, and the item shows as on track.
Every item underneath can also look healthy on its own terms. Each epic is progressing. Each sprint closes. The teams are doing exactly what they committed to, sprint by sprint. What changed is the amount of work the plan has to hold: it has grown past what the original estimate allowed for, and nothing measures the work against that estimate.
A slipping delivery date is a signal
When a date starts to slip, the reflex is to treat it as a delivery problem and ask why the teams are slow. Often that is the wrong question.
If throughput has stayed steady, a slipping deadline is usually an indicator that the requirements have changed or the work has outgrown the original plan:
- Scope added during refinement: edge cases, integrations and non-functional work that only became visible once the work was broken down.
- New or changed stakeholder needs: requests absorbed into the initiative without the commitment above it being revisited.
- Discovered dependencies: work on other teams or systems that the original estimate never included.
- External change: regulation, contracts or platform decisions that altered what "done" means.
Each of these is legitimate. The problem is not that the requirements changed. Not that scope was added. It's that the plan was never updated to reflect what was learned as the work was elaborated.
What a real check looks like
- Roll up the detail. Add up the estimated remaining work beneath the commitment.
- Translate it into time. Use the capacity of the teams doing the work to project when it could realistically finish.
- Compare it with the committed date. If the projected finish is later, the original plan has slipped, whatever the status says.
- Compare current scope with the original. Identify if scope has been added or changed since the plan was set. That usually explains the gap.
Reporting it honestly
The useful message is not "this item is red." It is:
- the committed date,
- where the current work projects to finish,
- and which requirement, scope, or work changes caused the difference.
That framing puts the conversation where it belongs. The decision is about scope and plan, not about the deadline: accept the larger scope and move the date, trim the scope back to the original, or add capacity. Each of those is far easier three months before the deadline than three days before it.
Tags: #PortfolioManagement #AgileDelivery #DeliveryPredictability