Sprint Forecasting
Forecast what your team will actually ship this sprint, not what the spreadsheet says. iftrue blends historical velocity, AI lift, unplanned work rate, and carryover drag into a realistic commitment number.
How we got to 38
3 tickets have carried over 3+ sprints
Consider cutting or splitting before committing again. They're costing 1 pt of velocity per sprint.
Sprint commitment forecast with confidence range
Unplanned work ratio and carryover drag factored in
Carryover radar for tickets stuck across multiple sprints
Pre-sprint sanity check before commitments are locked
Forecast inputs
Velocity alone lies
A six-sprint average ignores AI lift, unplanned work, and tickets that never close. iftrue blends four inputs so the forecast reflects how your team actually ships.
Sprint completion trend
Points completed vs committed, last 6 sprints. Outliers like vacation weeks and incidents are down-weighted.
AI lift
Measured velocity change since AI tool adoption. Applied to the baseline so the ceiling reflects today, not pre-Cursor days.
Unplanned work ratio
How much of each sprint has historically gone to unplanned bugs and support. Held back from commitment.
Carryover drag
Tickets bleeding across sprints drain velocity. The forecast accounts for the ones still lurking in your backlog.
Sprint trends
The charts your retro needs
Story point completion ratio, unplanned work ratio, and work distribution by type over the last 6 sprints. Every chart is an input to the forecast, and every chart is a talking point for retro.
- Completion ratio
- Points completed divided by points committed. Consistent undershoot means the team overcommits.
- Unplanned work ratio
- Share of each sprint burned on work that wasn't in the plan. Rising trend is a planning or quality signal.
- Work distribution
- Who finished what, by issue type. Spot engineers carrying bugs while others ship features.
Solid bars = completed. Dashed line = committed. Gap is overcommitment.
Trending up. Worth a retro discussion about scope protection.
Zombie tickets · carried across sprints
3 flaggedBitbucket marketplace installation missing callbacks
4 sprintsSprint average numbers in the team sprints tab is wrong
3 sprintsUnplanned work ratios don't add up to 100%
2 sprintsSuggested action
Cut the 12-point Bitbucket ticket, or split it into a 3-pt spike plus separate implementation. 4 sprints is too long.
Carryover radar
Kill zombie tickets
Every team has them: tickets that keep rolling over sprint after sprint, always "in progress", never done. iftrue surfaces them with a sprint counter per ticket so you can cut, split, or unblock before planning starts. One of these tickets drags down velocity more than it contributes.
The counter is visible on every sprint board, every retro, and rolled into the forecast. No more discovering in month three that the same ticket has been "nearly done" since January.
Pre-sprint sanity check
Catch overcommitment before it ships
Before your planning meeting ends, iftrue checks the draft commitment against the forecast and pings you in Slack if it's outside the safe range.
Sprint 24 is over-committed
Draft commit is 48 pts. Forecast ceiling is 44 pts (stretch). Last 4 sprints you missed target by an average of 6 pts when committing above forecast.
Suggest cutting 4-6 points before planning closes. PROJ-512 (5 pts) and PROJ-518 (3 pts) are the lowest-priority candidates.
Who it's for
Built for engineering leaders
Engineering Managers
Walk into planning with a number you can defend. Stop overcommitting because the PM asked for more.
Tech Leads
See which tickets have been stuck across 3+ sprints and either unblock them or cut them. Stop the zombie ticket cycle.
VPs of Engineering
Aggregate forecasts across teams to plan realistic quarterly delivery. Calibrate roadmaps against actual throughput.
Ready to transform your engineering organization?
Start your journey to data-driven engineering management. Book a demo to see how iftrue can help your team.