Right-Shifting Forecasts: Why Your Deadlines Keep Moving

WHY IT EXISTS Agile teams must plan with incomplete information. Forecasts provide a way to discuss the future without making false promises that crumble under new information. The term "right-shifting forecast" describes the natural, observable outcome when reality collides with initial estimates in a dynamic environment. It is a name for a symptom, not a prescribed practice.

THE MENTAL MODEL Treat a forecast like a GPS navigation app. Your initial forecast is the ETA when you start your trip. If stakeholders add new features (scope creep), it's like adding a new stop to your route. If a task is harder than expected (unforeseen complexity), it's like hitting unexpected road construction. In both cases, your ETA gets later. The forecast isn't "wrong"; it's updating with new, better information.

HOW IT WORKS This isn't a formal process, but an observable phenomenon. You can see it on a burn-up chart. If the line projecting the completion date keeps intersecting the total scope line further and further into the future, your forecast is right-shifting. This typically happens when new work is added to the backlog faster than the team can complete existing work, causing the scope line to rise steeply.

WHEN TO USE IT You don't "use" right-shifting; you observe it and manage the implications. The observation of a right-shifting forecast is a critical signal to talk with stakeholders. It's a diagnostic tool that should trigger immediate, transparent conversations about priorities, scope, and expectations. Use it to ask, "Given this new information, is this still the most important work? Are we willing to trade scope to meet the original timeline?"

WHEN NOT TO USE IT Do not use "right-shifting" as an excuse for poor planning or a lack of discipline. While some movement is natural in an agile environment, a forecast that shifts dramatically and constantly can indicate deeper problems. These might include an inability to break down work, a product owner who can't control the backlog, or crippling technical debt that makes velocity unpredictable. It is a signal to investigate, not a hall pass for missing dates.

ONE CANONICAL EXAMPLE A team has a 100-point epic and a stable velocity of 20 points per sprint. The initial forecast is a 5-sprint completion time. After Sprint 1, they have 80 points remaining. But in Sprint 2, stakeholders add 30 points of new scope. The total remaining work is now 110 points. At their velocity of 20 points/sprint, the new forecast is 5.5 more sprints (rounded to 6). The total project timeline has shifted from 5 sprints to 1+6=7 sprints. This two-sprint shift must be communicated immediately.