Sprint Estimation Reality 2026

Why publish another estimation report

The honest version of an estimation report is harder than the marketing version. The marketing version goes: "Story points are broken / planning poker is broken / AI fixes estimation / here's our framework / call our reps." The honest version notices that 43 years of estimation research, by serious authors with serious methodologies, broadly converges on the same handful of findings — and almost none of that literature gets cited in modern Agile or DevOps thought leadership.

We chose to publish Volume 0 before Volume 1 for three reasons.

First, the literature is mature and rarely surfaced. Boehm's 1981 Cone of Uncertainty is foundational and broadly replicated. Halkjelsvik & Jørgensen's 2012 meta-analysis of 200+ time-prediction studies put the average software overrun at about 30%. Jørgensen's 30-year program of research is the most comprehensive body of empirical work on the topic. Synthesising what's already known is the prerequisite for adding to it.

Second, pre-registering hypotheses before fielding is the difference between a research report and a press release with footnotes. The hypotheses we register today are the hypotheses we will test when our 500-respondent primary study fields — not the hypotheses we invent after looking at the data.

Third, the 2026 question is genuinely new even if 1981's framework still applies. Does AI-aided estimation improve calibration (accuracy), or only confidence? If AI raises confidence without raising calibration, sprint commitments will become more confident and more wrong — exactly the dynamic that produces the late nights, missed launches, and the engineer burnout we synthesise in our companion report on burnout and process debt.

The historical baseline 1981–present

The most-cited single source on software estimation is also the oldest. Boehm's 1981 book Software Engineering Economics introduced the Cone of Uncertainty as a model of estimation variance over the project lifecycle. The Cone is descriptive — what variance looks like in practice across observed projects — not prescriptive. At project inception, estimates have roughly 4× variance: a project budgeted at 100 person-weeks could legitimately turn out to be anywhere from 25 to 400. The cone narrows as decisions get locked in, reaching 1× (the actual outcome) at delivery.

Boehm's contemporaries — and the next 25 years of estimation research — broadly replicated the pattern. Magne Jørgensen's 30-year program of research (1995 through 2014) is the most comprehensive empirical body of work on software estimation accuracy in the field. The synthesis: expert judgment is roughly as accurate as formal estimation models (COCOMO, function points, etc.) for most software effort estimation; both are systematically optimistic; neither has been clearly improved by any one technique in 30 years.

Halkjelsvik & Jørgensen's 2012 paper "From origami to software development: A review of studies on judgment-based predictions of performance time" is the most-cited single meta-analysis. Across 200+ time-prediction studies — software, manufacturing, daily-life tasks, origami — the central finding is consistent: people are systematically optimistic about how long their tasks will take, and the bias does not narrow with practice on the same task.

Steve McConnell's 2006 book Software Estimation: Demystifying the Black Art is the closest the practitioner literature has to a standard reference. McConnell catalogues two-dozen estimation techniques (PERT three-point, planning poker, t-shirt sizing, group estimation, fuzzy logic, neural networks…) and argues that the choice of technique matters less than the discipline applied to it — calibration training, structured uncertainty bands, and explicit recording of historical accuracy.

The Standish CHAOS reports — the most-quoted commercial source on software project outcomes — have been heavily critiqued. Eveleens & Verhoef's 2010 paper reanalyses the Standish methodology and shows that the reports' headline "failure rate" is overstated due to definitional choices that systematically classify successful projects as failed. We cite Standish in our reading list with this critique attached; we do not cite Standish in the body without it.

What modern surveys show

The modern survey literature on estimation is thinner than the academic literature, because most engineering surveys focus on adoption and tools rather than calibration accuracy.

The 2024 Atlassian State of Teams report surveys ~5,000 knowledge workers and finds that ~70% of respondents say their teams routinely miss sprint commitments. The report does not measure calibration accuracy (the gap between confidence in an estimate and the empirical accuracy of that estimate), but it provides a useful proxy: routine missed commitments are inconsistent with well-calibrated estimation across a healthy variance of work.

The 2024 JetBrains State of Developer Ecosystem reports that ~64% of developers use story points for estimation and ~17% use hour-based estimates, with the rest using t-shirt sizes, three-point estimation, or no estimation at all. The survey doesn't measure accuracy of those estimates, but it documents what tools the population uses — important context for the Volume 1 primary study's stratification.

The Stack Overflow Developer Survey 2024 (n≈65,000) doesn't have an estimation-accuracy section, but reports that ~74% of professional developers identify "deadlines that don't reflect estimates" as a leading source of stress at work — consistent with the planning-fallacy literature's prediction that estimates produced under the bias produce deadlines that are systematically too tight.

The four landmark studies, side by side

The table below collapses the historical baseline into one frame. Read across the rows: each study answered a different question, with a different population, on a different time horizon. Read down the "key limitation" column: each is honest about what its design cannot conclude. Volume 1 picks a fifth position — calibration tasks on a primary survey of 500 senior software-delivery practitioners, with pre-registered hypotheses — to fill the gap none of these four cover at the modern AI-era practitioner scale.

The measurement gap nobody fills

Across the historical literature and the modern surveys, one fact stands out. Almost no engineering organisation measures its own estimation calibration. Teams measure velocity (story points completed per sprint), Atlassian and JetBrains measure tool adoption, Stack Overflow measures stress; almost no team measures "when our team said we were 80% confident in this sprint commitment, were we right 80% of the time?"

This is the gap Volume 1 fills. The Stride sprint-capacity-calculator — public, free, no-signup — is the measurement instrument for the primary study. Teams enter their planned sprint capacity inputs (team size, sprint length, PTO, meetings, on-call rotation, historical velocity), and the calculator outputs a calibrated sprint-capacity recommendation. Volume 1's primary-study question: for participants who use the calculator, does the measured accuracy of their subsequent sprint commitments improve over time? And does the improvement track participants' self-reported confidence?

What Volume 1 will measure

The Stride 2026 sprint-estimation primary study is two arms, cross-referenced.

The survey arm targets N=500 senior software-delivery practitioners (IC engineers ≥5 yrs tenure, engineering managers, staff+ engineers, eng directors, VPs). Recruitment is Prolific Academic for the panel arm with an organic top-up from the Stride newsletter, LinkedIn, and selected industry communities. Sample is balanced across role, company size, region, and AI-adoption stage.

The tool-usage arm analyses anonymised usage of the sprint-capacity-calculator, comparing planned-capacity inputs against post-sprint accuracy ratings opt-ed-in by users. Anonymisation enforces k≥10 cells; no individual user is identifiable in published findings.

Both arms are stratum-vs-stratum, never joined at the individual respondent level.

Pre-registered hypotheses

These are the five hypotheses we register on the Open Science Framework before fielding closes. They are also the hypotheses we test in October 2026.

1. H1 — Calibration gap. Teams' self-reported confidence in their sprint estimates will exceed measured calibration (Brier score) by ≥2× across the 500-person sample. Test: paired t-test on confidence vs measured calibration; Cohen's d + 95% bootstrap CI.
2. H2 — Story points don't solve it. Story-point and time-based estimates will show indistinguishable systematic bias (mean signed error) on the same task set. Test: paired t-test on signed-error magnitudes; effect size + Wilson 95% CI.
3. H3 — AI changes confidence, not calibration. Teams using AI-aided estimation tools will report higher confidence than non-AI teams, but their measured calibration error will be statistically indistinguishable. Test: ANOVA on confidence × AI-usage; ANOVA on calibration × AI-usage.
4. H4 (null) — Sprint length is independent of estimation accuracy. Sprint length (1/2/3/4 weeks) will not predict estimation accuracy after controlling for team size and tenure. The null is the finding. Test: linear regression with covariates.
5. H5 (exploratory) — Training ROI is size-dependent. Estimation-training ROI (calibration improvement per training hour) will be largest for teams ≤50 engineers. Reported with exploratory framing, not as a confirmed finding.

The pre-registration document — hypotheses, planned cross-tabs, exclusion criteria, weighting scheme, multiple-comparison correction (Benjamini–Hochberg FDR at q=0.05 for the planned family) — is linked below.

Methodology summary

The full methodology is on the companion page. The short version:

• Survey instrument: ~48 substantive items + 4 screening + 3 attention checks + 8 firmographics. Median completion 12 minutes. Includes 8 validated calibration tasks (Lichtenstein-style probability calibration questions on software-task time estimation) so we have a measured calibration score per respondent.
• Recruitment: Prolific Academic panel arm (~400 completes; effective CPI ~$3) + organic arm (~100 completes via newsletter / LinkedIn / industry communities). Organic responses carry a separate stratum flag in the dataset.
• Tool-usage arm: anonymised opt-in capture from the sprint-capacity-calculator. Q3 2026 cohort; k-anonymity ≥10 + Laplace differential-privacy noise (ε=1.0) on any cell-level summary.
• Statistics: 95% Wilson confidence intervals on every quoted percentage; Cohen's h for proportion comparisons; Cliff's delta for ordinal Likert; Cohen's d for continuous. Benjamini–Hochberg FDR correction for the planned family.
• Pre-registration: will be cross-registered on the Open Science Framework before fielding closes; the link will appear here once registration completes.

Dataset publication (Volume 1)

When Volume 1 lands, the survey dataset publishes under CC-BY-4.0: anonymised individual-response CSV, pre-computed cross-tab tables, JSON-Schema data dictionary, and aggregated tool-usage summary tables. Distribution as a single ZIP bundle plus a Zenodo DOI for permanent citability.

Limitations and what to expect

• English-language, predominantly Western sample. The Prolific panel skews toward US/UK/EU respondents; the organic top-up extends to APAC + RoW but not enough to support sub-regional analysis. Volume 1 reports findings as English-Western and explicitly flags this in every cross-tab.
• No juniors-only stratum. The Volume 1 design targets senior practitioners (≥5 yrs tenure) because the calibration questions assume a working baseline of software-estimation experience. A juniors-focused replication is a future study, not this one.
• Self-reported AI adoption stratum, not telemetry. We classify respondents into AI-usage cohorts by what they tell us. The State-of-AI Volume 0 report establishes that self-perception and measured behaviour disagree on AI; we apply that lens to our own classifications.
• The literature is moving. New estimation studies are appearing; if a major peer-reviewed study lands between Volume 0 and Volume 1, we will append a "Recent developments" note rather than rewriting the body.

Participate in Volume 1

If you are a senior software-delivery practitioner and would like to participate in the Volume 1 primary study (Prolific arm or organic arm), reach out to research@newlightai.com. If you are a researcher or journalist interested in the pre-registration, the dataset, or the calibration instrument, the same address reaches the editorial team directly.

References

1. Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall. (Revisited 2002 with Boehm & Turner, "The Cone of Uncertainty Revisited".)
2. Halkjelsvik, T. & Jørgensen, M. (2012). From origami to software development: A review of studies on judgment-based predictions of performance time. Psychological Bulletin 138(2), 238–271.
3. Jørgensen, M. (2014). What we do and don't know about software development effort estimation. Journal of Systems and Software 98, 142–157.
4. McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
5. Eveleens, J. L. & Verhoef, C. (2010). The rise and fall of the Chaos report figures. IEEE Software 27(1), 30–36.
6. Buehler, R., Griffin, D. & Ross, M. (1994). Exploring the "planning fallacy": Why people underestimate their task completion times. Journal of Personality and Social Psychology 67(3), 366–381.
7. Lichtenstein, S., Fischhoff, B. & Phillips, L. D. (1982). Calibration of probabilities: The state of the art to 1980. In Kahneman, Slovic & Tversky (eds.), Judgment Under Uncertainty.
8. Atlassian State of Teams Report (2024). Atlassian Work Innovation Lab.
9. JetBrains State of Developer Ecosystem (2024). JetBrains.
10. Stack Overflow Developer Survey (2024). Stack Overflow.

Frequently asked questions

Related work

Reference this Volume 0 in your own writing using the citation below. The dataset DOI and the Volume 1 primary-findings citation will be added at the same URL when Volume 1 publishes — readers who cite Volume 0 today will automatically cite the most current version when crawlers re-fetch.

Stride Research. (2026). Sprint Estimation Reality 2026 — Volume 0: Landscape synthesis and pre-registered design. Newlight Solutions. https://www.stride.page/research/sprint-estimation-reality-2026