← Field notes
Forecasting

Why late work hurts more: the S-curve nobody plans for

Sprint work does not finish in a straight line — it finishes on an S-curve. That single fact is why a late epic hurts far more than its point count suggests, and why naive burndown lies to you at exactly the wrong moment.

KalMatrix·June 24, 2026·6 min read

Open any sprint report and you will find a burndown chart with a straight diagonal “ideal” line running corner to corner. It is a comforting image: start with 40 points, end with zero, burn them down evenly, one slice per day. It is also completely unlike how software actually gets finished. Real sprints do not burn down in a straight line. They finish on an S-curve — and the gap between those two shapes is where most missed sprints are born.

Why work bends into an S

Think about how a real sprint unfolds. The first days are slow: people are wrapping up last sprint’s tail, spinning up branches, reading code, waiting on the first reviews. Then the middle accelerates — context is loaded, PRs start merging, the team hits its stride. And then the end slows down again, hard: the last stories are the gnarly ones, the integration bugs surface, reviews queue up because everyone finished at once, and the trickiest ticket turns out to depend on the second-trickiest.

Plot that and you get an S: a flat shoulder at the start, a steep climb through the middle, and a long tail flattening toward the deadline. Every experienced delivery lead knows this shape in their gut. They just have never had a forecast that respects it.

A straight line assumes the last point is as easy to land as the first. Anyone who has shipped software knows the opposite is true — the last mile is uphill, and it is where sprints go to die.

Why late work compounds

Here is the part naive burndown gets dangerously wrong. It treats every remaining point as interchangeable and equally likely to land. So an epic that slips by two days early in the sprint looks like a small, recoverable wobble. But that same two-day slip near the end is catastrophic — because it lands the work into the flat tail of the curve, where there is no acceleration left to absorb it. There are no fresh review cycles, no slack, no runway. Late work does not add linearly. It compounds.

Picture the CHK checkout rewrite again. A Stripe webhook epic is running four days behind. On a burndown chart, the “remaining” line barely twitches — it is only a handful of points. But those points sit at the top of the S-curve, in the region where the team has no capacity to recover, and they gate fourteen downstream points that cannot even start until the webhook lands. A naive chart shrugs. The reality is a near-certain miss. The shape of the curve is the difference between those two readings.

A forecast that knows how teams finish

KalMatrix forecasts each active sprint with an S-curve burn-up — a model built on the observation that real teams accelerate through the middle and decelerate at the end. Instead of a single optimistic “ideal” line, it produces a calibrated probability that the sprint will miss, given the pace you are actually on and where in the curve the remaining work sits.

  • Calibrated P(miss) — a real probability for each active sprint, not a color-coded vibe.
  • Late-lands-late — the model knows work slipping into the tail carries more risk than the same work slipping early.
  • Confidence bands — a range, not a false-precision point estimate, so you can see how much the forecast actually knows.
  • Honest about thin evidence — early in a sprint, or on a new team, it says the evidence is thin instead of inventing certainty.

Why we back-test on your own sprints

A forecast you cannot check is just a confident guess. So every KalMatrix forecast is back-tested against your team’s own closed sprints — we replay history, ask what the model would have predicted at each point, and compare it to what actually happened. The demo organization’s current figures are published on our track record page, read live from the product itself rather than typed into a slide — and critically, the number you are shown comes attached to its own track record. You are never asked to trust the forecast on faith. You are shown how often it has been right for your team.

The point of a calibrated forecast is not to be impressive. It is to be trustworthy enough that you will act on it two days early — while a slip is still recoverable — instead of confirming it two days late.

Gut feel is not worthless; it is just unevenly distributed and impossible to defend in a planning meeting. Naive burndown is worse — it dresses up a straight-line assumption as data and reassures you at precisely the moment you should be worried. An S-curve forecast, calibrated and back-tested, gives you the one thing both of those lack: a number you can put your name on, early enough to do something about.

Stop reading about it. Read your own brief.

The demo is a fully-populated workspace — real sprints, real forecasts, the same daily diagnosis this post describes. No signup, nothing to configure.

← Back to the blog

Keep reading

All field notes
Delivery truth

Your Jira board is lying to you

Every “Done” column hides a question the board can’t answer: is there merged code behind it? The gap between board-done and code-done is where slipping sprints quietly wait — until demo day makes them loud.

Read the note
Product

From dashboards to decisions

A dashboard reports the past and leaves the thinking to you. A chief-of-staff brief does the thinking and hands you a decision. Here is why one clear call a day beats ten charts that make you feel informed.

Read the note
Delivery

Why your sprints keep slipping — and the four causes hiding in your data

Roughly four in five agile teams roll work over every sprint. It is almost never a capacity problem. It is four specific, findable causes — and they are already sitting in your Jira and Git history.

Read the note
Leadership

How a CTO can actually know if the team will hit the deadline

Most status turns red overnight in week eleven — after the recovery options have expired. Here is how to get a defensible read on a deadline early enough to change the outcome, without micromanaging a single engineer.

Read the note
Estimation

Story points can’t forecast a date — and were never meant to

Velocity is a useful planning heuristic and a terrible crystal ball. If you are turning a story-point average into a delivery date, here is why it keeps betraying you — and what to denominate your forecast in instead.

Read the note
Delivery truth

Watermelon status: how to catch a project that’s green outside, red inside

Watermelon reporting is the most expensive lie in delivery because it is comfortable. Here is how green-on-the-outside, red-on-the-inside status forms, and how to catch it with evidence instead of accusation.

Read the note
Forecasting

Monte Carlo vs velocity: how to forecast a delivery date you can defend

A single-date forecast from a velocity average is a promise you will almost certainly break. A probabilistic forecast gives you a range and the odds. Here is the difference — and why leaders trust the range.

Read the note
Leadership

Engineering metrics that matter — without surveilling your developers

The metrics that predict delivery and the metrics that destroy trust are not the same list. Here is how to measure the system without measuring the people — and why the distinction is the whole game.

Read the note