Friday afternoon, end of sprint. You realize you're going to miss the goal. Three tickets are still In Progress. Two others haven't been touched since Tuesday.
This isn't a surprise. The signals were there on Wednesday. You just didn't have a way to see them.
A sprint forecast solves this. Done right, it tells you by midpoint whether you're on track, at risk, or heading for a miss. Here's how it works.
What a sprint forecast actually is
A sprint forecast is a prediction of how much work your team will complete by the end of the current cycle, based on your current pace.
It's not a guarantee. It's a signal that tells you:
- "At current pace, you'll complete 18 of 24 planned points"
- "Two engineers are behind their historical average this sprint"
- "If the current blockers aren't resolved by Thursday, you'll miss the goal"
That information, available on Wednesday instead of Friday, lets you do something about it.
The simple version: burndown math
The most basic sprint forecast is a burndown calculation.
Take your total planned work. Divide by the number of days in the sprint to get your expected daily completion rate. Then compare that to what's actually been completed day by day.
If you're on day 7 of a 10-day sprint and you've completed 40% of your planned work, you're behind. You need to complete 60% in the remaining 30% of the time.
Most project management tools show some version of this. Linear shows you a cycle progress bar, but not a projection line.
The better version: velocity-adjusted forecast
The burndown math works but it's not very accurate. It assumes all remaining work will be completed at a constant rate. That's rarely true.
A better forecast uses your team's historical velocity as the baseline:
- What does this engineer typically ship in a 2-week sprint? (historical average)
- How much have they completed so far this sprint?
- Given their remaining work and their typical pace, how much will they finish?
Roll this up across the team and you get a much more realistic forecast.
This is the difference between "we're at 40% of planned work on day 7" and "based on your team's typical pace, you'll finish 19 of 24 points, with a 70% probability of hitting the goal."
When to check your forecast
Check it at three points in the sprint:
Day 1 to 2 (planning check): Is the planned scope realistic given your team's velocity? If your historical average is 22 points and you planned 35, you already know the outcome.
Midpoint (usually end of day 5 in a 2-week sprint): Are you on track? Are any team members significantly behind pace? Any blockers that haven't been resolved?
Day 8 to 9 (final adjustment): What can still move? At this point, a miss is often unavoidable, but you can adjust scope or communicate early with stakeholders.
Building a forecast in Linear
Linear doesn't have a built-in sprint forecast. Here's how to approximate one manually:
Step 1: Open your active cycle and filter by assignee.
Step 2: For each team member, count their completed vs. remaining work.
Step 3: Look at their velocity in the last 3 to 5 cycles (you'll need to open each past cycle or export data).
Step 4: Compare current completion rate to historical average and estimate remaining output.
This takes 20 to 30 minutes per sprint and requires you to have already built a velocity history somewhere.
SprintIQ: automatic sprint forecast for Linear
SprintIQ connects to your Linear workspace in 30 seconds and computes a real-time sprint forecast automatically.
At any point in your sprint, you can open SprintIQ and see:
- How much work has been completed vs. planned, per person
- A forecast of sprint completion based on your team's historical velocity
- Which team members are behind pace and by how much
- Blockers that are currently holding up completion
No manual calculation. No spreadsheets. The forecast updates automatically as tickets are completed.
Check it Wednesday morning instead of Friday afternoon. That's the difference between fixing a problem and reporting one.
Free to start. No credit card required.