Next Sprint Planning

What could this team take on next sprint, based on what they've actually delivered? This describes a history — it does not promise a fortnight.

What you see

  • "A commitment this team has usually met," drawn from the last up to 6 finished sprints.
  • A "Suggested Starting Point" figure — a single item count. This is not clickable; there's no drill-down to the sampled sprints from here.
  • A note if there are fewer than 3 finished sprints to learn from, saying the forecast should be treated as a first sketch.
  • A table of what the team has delivered per sprint, by kind of work: Planned Work, Bugs, Exploration — each with three columns, At least (a conservative floor), Usually (the middle case), and A good sprint (a strong but real case, explicitly "not a target").
  • A note when a row can't honestly be given a floor at all — it reads "Varies too much" rather than a bare zero.
  • A reliability line — "of everything committed in those sprints, the team delivered X%" — or, when that can't be worked out, an explanation of why.
  • A standing note that this forecast assumes the team's usual capacity and does not account for known holidays or part-time weeks in the coming sprint — Sprint Capacity has the real figure for the sprint that's actually running.

How we calculate it

History used
The last up to 6 finished sprints. The currently running sprint is never included.
Bucketing
Each historical item is classified the same way Cycle Time classifies it — bug/defect/issue types count as Bugs, research/spike/analysis types count as Exploration, everything else counts as Planned Work.
The forecast method
A statistical simulation that repeatedly samples one whole historical sprint at a time and reads all three kinds of work from that same sprint together — preserving the real pattern that a sprint where bugs ate the week is also a sprint where planned work fell behind. The same history always produces the same forecast; nothing here is randomised between refreshes.
"At least" / "Usually" / "A good sprint"
The 15th, 50th and 85th percentiles of the simulated outcomes for each kind of work.
"Varies too much"
Shown when the team does deliver that kind of work on average, but the amount swings so widely that even the conservative 15th-percentile floor rounds down to zero.
Why the total can differ slightly from the three rows added together
The total is computed from the three kinds of work's unrounded averages together, not from summing the three already-rounded rows — so it can differ from their visible sum by up to about 2 items.
Capacity assumption
The forecast always assumes the team's usual capacity. It does not currently adjust for a specific upcoming sprint's known holidays or part-time weeks — that adjustment is not applied, even though the underlying engine could in principle support it.
Reliability
The average of each historical sprint's own completed-versus-committed ratio. If every sprint in the window lacked a real Day-1 baseline, this line is replaced with an explanation rather than a misleading percentage.
Low confidence
Fewer than 3 finished sprints in the window.

What you can click through to

Nothing. There is no drill-down from the "Suggested Starting Point" figure or the bucket table to the historical items behind them on this view today.

Tip

Next Sprint Planning deliberately never phrases its output as a promise — "a good sprint" is explicitly not a target to hold the team to, just the strong end of their own real history.

Known limits
  • No drill-down to the sampled historical items.
  • A team with sprints but none finished yet sees a plain "nothing to learn from yet" message.
  • The forecast does not adjust for a known upcoming absence or holiday — check Sprint Capacity for the real number once the next sprint exists.