"When will checkout be done?" is the question, and "it depends" is the honest answer nobody wants. The good news is that you can turn "it depends" into a range worth saying out loud, with three numbers you already have and about five minutes of arithmetic.
The three numbers are the story points left in the epic, the team's velocity over the last few sprints, and how much the epic has grown per sprint so far. The first two give you the forecast everyone does. The third is the one that makes it true.
The forecast everyone does
Points remaining divided by velocity. If checkout has 64 points left and the team finishes about 17 points a sprint, that is 3.8 sprints, so call it four.
We covered this in epic and initiative burnup charts, and it is a good starting point. It is also wrong in two predictable ways, and both push the date later.
Use a velocity range, not the average
Here are the team's last five sprints: 14, 19, 17, 21 and 15 points. The average is 17.2. But the team did not do 17.2 in any of those sprints, and the average hides how much it moves around.
So forecast with the edges. At the slowest recent pace, 14 points, the 64 points take 4.6 sprints. At the fastest, 21 points, they take about 3. The honest statement is "three to five sprints," and the spread itself tells you something: a team whose velocity swings from 14 to 21 cannot promise a single sprint, and shouldn't.
If you want to know where your velocity actually comes from, and why a single good sprint should not move it, how to calculate sprint velocity goes into it properly.
Subtract the scope growth
This is the step that changes the answer.
Look at the epic's total size over the sprints it has run. Say checkout was planned at 70 points three sprints ago and it is 88 points now. It has grown by 18 points in three sprints, so about 6 points a sprint. Stories split, a payment edge case turned up, someone added "save card for later."
That growth does not stop because you started forecasting. So the team is not closing the gap by 17 points a sprint. It is finishing 17 and the epic is adding 6, which means real progress toward done is 11 points a sprint.
Redo the range with that. At 14 minus 6, which is 8 points a sprint, the 64 points take 8 sprints. At 21 minus 6, which is 15, they take about 4.3. The average case, 17 minus 6, gives 5.8.
The simple division said four sprints. The honest range is just over four to eight, most likely six. That is a very different conversation to have with the person who asked, and a much better one to have now rather than in sprint five.
What about stories that have no points yet?
Every epic has a tail of stories that are still one-line placeholders. A points total quietly counts each of them as zero, which makes the remaining work look smaller than it is.
Give each unestimated story the average size of the estimated ones. If the epic's estimated stories average 4 points and there are five without a number, add 20 points to what is left. It is crude. It is also far closer to the truth than zero, and it gives you a reason to get those stories into refinement soon.
How to say it to a stakeholder
Say the range, and say what would narrow it.
"Checkout is somewhere between five and eight sprints away, most likely six. It has been growing by about six points a sprint, so if we can freeze scope after this sprint, the early end of that range gets much more likely."
Two things happen when you put it that way. The stakeholder gets a date they can plan around, because the late end is one you can actually stand behind. And the scope growth becomes a shared decision instead of the team's private failure: every "while you're at it" now visibly moves the date, and the person asking can see the trade.
Then update it every sprint. The range should narrow as the remaining work shrinks. If it is not narrowing, the epic is growing as fast as you finish it, and that is worth raising before anyone asks again.
When the forecast is not worth doing
If an epic is two sprints of work, skip all of this. The error in the forecast is bigger than the thing you are forecasting.
It is the same if the team is brand new. Without three or four finished sprints there is no velocity to speak of, only hope with a number on it. Forecast in that case by saying so: "we will know much better after two sprints" is a real answer, and a better one than a confident date you have no basis for.
Where Scrumpy helps, and where you still do the maths
Scrumpy gives you the inputs. The team's velocity is the average of its last five finished sprints, and it shows up against the committed points when you plan the next one. The dashboard shows each open epic's completion by points, and every epic with a target date gets a status: on track, behind, overdue, or delivered, with "behind" meaning completion has fallen more than ten percent behind the share of time already gone.
What it does not do is draw the range for you, or track how the epic's size has changed over time. So the scope growth figure is one you take by noting the epic's total points at each sprint review. One number, once a sprint. It is the most useful line in the whole forecast, and it takes less time than the meeting where someone asks why the date moved.
Frequently asked questions
How do you forecast when an epic will be done?
Divide the story points left in the epic by the team's velocity, using your slowest and fastest recent sprints rather than the average alone, so you get a range of sprints instead of a single date. Then subtract how much the epic's scope has been growing each sprint from the velocity, because an epic that gains points every sprint finishes later than the simple division suggests.
Why is an epic forecast usually too optimistic?
Because the simple calculation assumes the epic's scope holds still, and it rarely does. Stories split, work gets discovered and small requests get added, so an epic might grow by several points every sprint. If the team finishes 17 points a sprint while the epic grows by 6, the real progress toward done is 11 points a sprint, not 17.
How do you forecast an epic with unestimated stories?
Count the unestimated stories and give each one the average size of the stories in the epic that are already estimated. It is a rough placeholder, but it is much closer to the truth than counting those stories as zero, which is what a points total does by default. Replace the placeholders as the stories get refined.
Should you give stakeholders a date or a range for an epic?
A range. A single date sounds precise but carries no sense of how sure you are, and it becomes a promise the moment it is said out loud. A range such as late October to mid-November states the uncertainty honestly, and you can narrow it every sprint as the remaining work shrinks.
