In most cases, don't re-estimate a story mid-sprint just because it turned out harder than expected. Keep the original points, finish it, and talk about the surprise in the retro. Re-estimate (or better, split off a new story) only when the scope changed: someone added requirements after the team committed. For unfinished stories, carry them over with their original points and count them in the sprint where they reach Done.
The reason is simple: velocity only works for forecasting if it compares estimates made with the same level of knowledge. Your backlog estimates are made before work starts. If you re-point stories after you've seen the hard parts, your velocity measures hindsight, and hindsight isn't available when you estimate the rest of the backlog.
Scope change vs discovery: the core rule
Every "should we re-point this?" question comes down to one distinction.
Scope change: the work itself changed. The product owner adds two-factor authentication to a login story after planning. The design is replaced. A compliance requirement appears. This is different work from what the team estimated.
Discovery: the work is the same, but harder than you thought. The legacy auth code is messier than expected. The email service has rate limits nobody knew about. Tests take twice as long to write. This is exactly the uncertainty story points are meant to absorb.
Treat them differently:
- Scope change: split the new requirement into its own story, estimate it, and decide with the product owner whether it goes into this sprint (and what comes out) or the backlog. If splitting is truly impossible, re-estimate and note why.
- Discovery: keep the original estimate. Write one line on the ticket about what surprised you. That note is what makes the next similar estimate better.
If you re-point discoveries, the lesson disappears. The next email-notification story gets a 3 again, because the record now says email work is reliably what you expected.
Decision table
| Situation mid-sprint | Re-estimate? | What to do |
|---|---|---|
| Story is harder than expected, same acceptance criteria | No | Keep points; note the cause on the ticket; discuss in retro |
| PO adds a new requirement after planning | Split | New story for the addition, estimated separately; negotiate what leaves the sprint |
| Design or approach replaced by stakeholder decision | Yes, or split | Treat as new work; record original and new estimate and the reason |
| Story turns out to be much bigger (e.g. a 5 that is really an epic) | No, remove it | Pull it from the sprint with the PO, break it down in refinement, estimate the new stories |
| Spike reveals the follow-up story is huge | No | The story wasn't ready; send it back to refinement |
| Story turns out smaller than expected | No | Keep points; it evens out with the ones that ran over |
| Story split for parallel work, no new scope | No | Divide the original points across the parts; total stays the same |
| Dependency on another team changes what you have to build | Split | New story for the extra work; original keeps its points |
| Bug found in the story's own code before Done | No | That's part of finishing the story |
| Unrelated production bug pulls the team away | No | Track it as unplanned work; don't touch the story's points |
Two rules of thumb sit underneath this table: points describe the work as understood at commitment, and new work gets its own ticket.
Should you re-point unfinished stories at sprint end?
This is the most common version of the question, and teams handle it in three ways.
| Approach | How it works | Effect on velocity | Verdict |
|---|---|---|---|
| Carry over, original points | Unfinished story moves to next sprint unchanged; full points count when it's Done | Zero in sprint 1, full in sprint 2; averages out over 3+ sprints | Recommended default |
| Re-point the remaining work | 8-point story gets re-estimated as "3 left" for next sprint | Total credited = 3, not 8; velocity understates real delivery | Avoid: you lose 5 points of work from your history |
| Partial credit | Credit 5 of 8 in sprint 1 for "60% done" and 3 in sprint 2 | Looks smoother but counts unfinished work | Avoid: "60% done" is a guess, and it hides the carry-over problem |
Why "carry over with original points" works
A worked example. A team has an 8-point story at 70% done when sprint 4 ends.
- Sprint 4: completed 22 points (the 8 doesn't count).
- Sprint 5: the story finishes along with 26 points of other work. Velocity = 34.
- Average of the two sprints: (22 + 34) / 2 = 28.
That's the same average the team would have had if the story had finished on the last day of sprint 4 (30 + 26 = 56, / 2 = 28). Velocity averaged over several sprints isn't harmed by carry-over. Single-sprint numbers are lumpy, and that's fine.
Now look at re-pointing the remainder as a 3. Sprint 5 shows 26 + 3 = 29, so the two-sprint average drops to 25.5. The team delivered the same work, but their history now says they're 2.5 points per sprint slower, and their next forecast will be too pessimistic.
When splitting a carried-over story is legitimate
Sometimes part of an unfinished story is genuinely finished, tested and could ship by itself, and the rest is a separable piece. In that case, splitting is reasonable:
- Create a new story for the remaining work, estimated fresh in refinement.
- Reduce the original to just the completed part and estimate that part as it was originally understood. Don't just credit it with whatever's left over.
- Mark the original as Done in the sprint where it met the Definition of Done.
Be honest about it. If the "done" part can't be demonstrated to the product owner on its own, it isn't done, and the whole story carries over.
If carry-over happens every sprint
Occasional carry-over is normal. A story carrying over every sprint is a sign of something else:
- Stories too big. Anything at 8 or more points for your team is a split candidate. See estimating large epics.
- Too much work started at once. Five stories at 80% is worse than three at 100%. Limit work in progress.
- Overcommitting. If committed regularly exceeds completed by 20% or more, plan closer to your average (see how to calculate team velocity).
- Stories that weren't ready. Unclear acceptance criteria discovered on day 3 cause most mid-sprint surprises. The user story readiness checklist fixes that upstream.
What happens in Jira when you change points mid-sprint
If your team uses Jira's Velocity Chart, know how it reacts:
- Commitment is the total estimate when the sprint started. Changing a story's points later doesn't change Commitment.
- Completed uses the estimate at sprint close. So if you bump a 5 to a 13 mid-sprint and finish it, Completed counts 13, and your velocity is inflated by 8 points of hindsight.
- The Sprint Report marks estimate changes during the sprint. Check it before a retro; it shows which stories were re-pointed and when.
- Stories added mid-sprint count in Completed but not Commitment, which is why Completed can exceed Commitment in a sprint where scope was added.
That second point is the practical reason the "don't re-point discoveries" rule matters in Jira. Every upward re-point at sprint end goes straight into your velocity.
A team policy you can copy
Put something like this in your working agreement so the question is answered once:
Re-estimation policy
- Story points reflect the estimate at sprint commitment.
- If work is harder than expected but the acceptance criteria haven't changed, we keep the points and add a one-line note on the ticket about what surprised us.
- If requirements are added after commitment, the addition becomes a new story. The PO decides whether it enters this sprint and what leaves.
- If a story turns out to be far bigger than estimated, we pull it with the PO and break it down in refinement.
- Unfinished stories carry over with their original points and count in the sprint they're Done. No partial credit.
- We review notes on surprised stories at the monthly retro.
Run it for 3 or 4 sprints before judging it. The point is consistency, because a velocity built from mixed rules can't be used to forecast anything.
Scenarios
"The story we estimated at 5 needs a database migration nobody saw." Discovery. Keep the 5. Note "required schema migration not visible in story" on the ticket. In the retro, ask whether similar stories need a migration check in refinement.
"Halfway through, the PO says it also needs to work offline." Scope change. New story: "Offline support for X." Estimate it in a quick huddle or at the next refinement. If it must be in this sprint, the PO picks something of similar size to drop.
"We're on day 8 and this 13 obviously won't finish." Don't re-point. Talk to the PO now, not on day 10: can a valuable slice be finished this sprint? If yes, split as described above. If not, carry it over whole and treat it as a sign the story was too big.
"It was a 3 but took one afternoon." Keep the 3. Over-estimates and under-estimates cancel out over a few sprints. If small stories are consistently over-estimated, that's a calibration issue, covered in calibrating story points.
Tracking surprises without re-pointing
You still want to learn from stories that went sideways. A lightweight log is enough:
| Story | Points | Type | What surprised us |
|---|---|---|---|
| AUTH-123 | 5 | Discovery | Legacy auth migration required |
| AUTH-124 | 3 → split | Scope change | 2FA added on day 3; new story AUTH-131 (5 pts) |
| NOTIF-77 | 3 | Discovery | Email provider rate limit; needed a queue |
Review it monthly. Patterns emerge quickly: "everything touching billing runs over" is a reason for a spike or a reference story, not for re-pointing.
When the team does need to estimate a newly split story mid-sprint, a quick round of hidden-vote planning poker takes a couple of minutes and stops one person's number becoming the estimate. Alignlee is free and doesn't need accounts, so you can start a room from a stand-up without setting anything up.
FAQ
Should you re-estimate stories mid-sprint?
Usually not. If the story is harder than expected but its scope hasn't changed, keep the original estimate and record what surprised you. Only re-estimate, or preferably split into a new story, when requirements were added or changed after the team committed.
Should you re-point unfinished stories?
No. Carry the story over with its original points and count them in the sprint where it reaches Done. Re-pointing the remainder throws away the points for work already done and makes your velocity look slower than it is.
How do you handle carry-over story points?
The carried-over story counts zero in the sprint it didn't finish and its full original value in the sprint it does. Averaged over three or more sprints, this gives the same velocity as if it had finished on time. Only split it if the completed part is truly done and could ship by itself.
Does changing story points mid-sprint affect velocity in Jira?
Yes. Jira's Commitment is fixed at sprint start, but Completed uses the estimate when the sprint closes, so raising points mid-sprint inflates that sprint's velocity. The Sprint Report shows which estimates were changed during the sprint.
What's the difference between scope change and discovery?
Scope change means the work itself changed, for example new requirements or a different design. Discovery means the same work turned out harder than expected. Scope changes get a new story or a new estimate; discoveries keep the original estimate and become learning for future estimates.