While estimating user stories, we are assigning story points based on complexity. If we get unexpected situations like server unreachable, network down, dependent items, or delays, can we increase the story points for a user story in the middle of a Sprint, or request that the user story roll over into the next Sprint?

In addition, imagine that we completed a user story on time but we did more background work than visible in the story. Can we increase the story points for that story after the fact?

4 Answers 4


Story points help the team plan for future sprints. If the team learns more about a story and wants to increase the number of points for future sprint planning meetings then that's fair enough.

I would be extremely hesitant about increasing the estimate of points for the current sprint as a way of justifying incomplete work however. I suspect that could give the wrong impression and erode confidence in future estimates. There are other ways to tackle a story that turns out bigger than expected: A) split it and finish the bits you can complete; B) continue with the present story as far as you can; C) ask the PO to substitute something else and roll the story over to a future sprint.

Options B and C can be more attractive than they seem if you put the story back on the backlog with its original estimate. On the principle that a story is either 100% done or 0% done, an unfinished story shows up as a temporary reduction in velocity in the current sprint followed by a increase in velocity of a future sprint (because it retains the same estimate even though it is partially completed). The trend in velocity makes the impact clear and demonstrates something that the team can learn from.

It's also worth bearing in mind that story points don't need to be based purely on perceived complexity. Risks, unknowns and past experience are all good things to consider when making points estimates.

  • 1
    Velocity shouldn't increase, because stories on the Product Backlog should be re-estimated the next time they're in scope for Sprint Planning. They aren't victory points; story points represent how much effort a story will take to complete from its current state, not how much effort was previously consumed. Anything else will fundamentally break meaningful per-Sprint capacity planning and undermine the done/not-done dichotomy. See pm.stackexchange.com/q/20645/4271 for a related issue.
    – Todd A. Jacobs
    Commented Jun 22, 2022 at 4:54
  • 1
    @Todd, Your comment and your related answer have made me rethink. It does make more sense to re-estimate for future sprints based on what the team has learned. Thanks for pointing that out.
    – nvogel
    Commented Jun 29, 2022 at 12:23

TL;DR: Don't mess with story points.

They are an estimation tool, you use current knowledge at time of estimation to come up with a number. Any unexpected delay may cause you to deliver less than was initially planned, that's ok. You could not anticipate it, but you should not retroactively change your estimate.

After your sprint is done, you will use the total number of story points of completed stories to update your velocity, so your next sprint can be planned based on better numbers. Maybe your velocity goes down because your IT operations department is having issues delivering the service quality that you expect? Maybe someone is sick? By adjusting the velocity you take this into account for the next sprint.

However, the story points already assigned to stories in the active sprint must not be touched, because that would occlude the actual issues at hand. You may modify story points for backlog items when you learn something about the story itself which indicates that your initial estimate was likely wrong. But you should not include external factors that are completely unrelated to the story itself, especially not ones that you can't know at the time of estimation.

When you find that particular kinds of stories consistently take more effort than you estimate (maybe because you underestimated the bureaucratic work involved in getting a new server VM commissioned) you can use that knowledge to make better estimates in future.



I provide a little more dos-and-don'ts below, but here's the executive summary:

  1. Don't conflate level-of-effort with complexity, although they can be related.
  2. Don't treat story points as "victory points" or "effort expended"; they should be treated as level-of-effort estimates to determine if they are likely to fit within the time box of a single Sprint.
  3. Don't automatically roll over user stories if you're using a time boxing framework like Scrum. Other non-Scrum frameworks may have different rules or guidelines.
  4. Don't miss the opportunity to continuously re-evaluate, inspect, and adapt your planning and estimation processes to ensure you have sufficient slack and a defined process for handling overflow or mis-estimations.

User Stories are Primarily About Level-of-Effort

[W]e are assigning story points based on complexity.

This is only part of how one should estimate user stories. Mike Cohn, author of User Stories Applied and other books on the topic, has occasionally taken both sides of the argument of whether complexity should be a factor in estimation. However, the generally-held consensus among experienced practitioners is that story points should primarily reflect a relative level-of-effort compared to a baseline story, e.g. a 2-point story will require twice as much effort as a 1-point story.

Of course, the cone of uncertainty and the complexity inherent in a user story (among other factors) will potentially impact the level-of-effort required to deliver the story, so you should take those things into account when estimating and planning. You can do this by applying suitable "fudge factors," or by splitting stories or creating story spikes to reduce uncertainty and create bounding boxes for your estimates.

User Story Scope Problems

If we get unexpected situations like server unreachable, network down, dependent items, or delays, can we increase the story points for a user story in the middle of a Sprint[?]

No, you should not change the story points estimated for a Product Backlog item during or after the Sprint. The story points are a planning and estimation tool. If the planning or estimation were wrong, you actually need the original data from the original estimate to properly track velocity. That said, some systems do track "planned story points" and "consumed story points" as separate metrics, but overall this is an anti-pattern where velocity is being used as a proxy for measuring team or individual productivity rather than as a feedback mechanism to improve the estimation and planning process.

Note: The Product Backlog and Sprint Backlog are different things. If you maintain a separate Sprint Backlog (where items are often estimated in 1/2 to 2-day increments rather than story points), you can certainly decompose, move, or re-estimate your Sprint Backlog items to reflect the current reality of what the team is doing so long as it doesn't endanger the current Sprint Goal or your non-Scrum objective for the current Sprint. However, the original planning estimate for the Product Backlog item should never change.

If the expected scope, complexity, or level-of-effort for a Product Backlog expands during the Sprint, or the level of effort is significantly off from the planned level of effort, then you should follow your team's process for escalating the matter. If you were following Scrum, the escalation process would look like this:

  1. Determine whether the user story's mis-estimation puts the Sprint Goal at risk.
  2. Discuss the scope, challenges, and value of the user story within the current Sprint with the whole team, including the Product Owner.
  3. The Product Owner is empowered to negotiate the scope of Product Backlog items downwards for the Sprint, or to call for an early termination of the Sprint and a return to Sprint Planning if the Sprint Goal is at risk.
  4. The whole team should definitely discuss the estimation process, available slack for handling unforeseen events, and how to handle "known unknowns" in its Sprint Retrospective before re-estimating stories like these.

Changing the story points for a Product Backlog item after the Sprint is completed (assuming the story is done per the Definition of Done) is an attempt to get credit for effort expended rather than increments delivered. This is such a whiffy agile anti-pattern that I will simply say that doing this undercuts the entire basis for using story-point estimation in the first place. Do not do this.

Rolling Over User Stories

[Can we] request that the user story roll over into the next Sprint?

If you're following canonical Scrum, the answer is "no." In the Scrum framework, incomplete user stories are simply not done and must be placed back onto the Product Backlog for re-prioritization by the Product Owner and (possibly) selected for inclusion in a future Sprint where that user story is needed to meet that Sprint's current Sprint Goal. For more on this, see the following related answers:

Of course, if you're using some other agile framework that doesn't require either time boxing or a coherent Sprint Goal, you may be able to simply roll stories over. I would personally still consider that an anti-pattern since the agile process you've described in your question implicitly uses Sprints for time boxing, but if your framework and working agreements permit rolling over work without re-estimating and re-planning, then go ahead and do that. Just don't waste the opportunity to inspect-and-adapt your estimation and planning processes so that this doesn't become a routine occurrence!

See Also

The following are Scrum-oriented, but seem relevant to the questions you're asking. They may provide some additional context for you.


Story points are used to measure the overall effort required to complete a product backlog item. In my opinion, changing the story points during/after a sprint is not fair as it hinders the transparency of the scrum framework. If the task is not completed in the given sprint, then it can be noted and discussed at the sprint retrospective. This allows the team to discuss what went wrong, and what improvements are needed. This way the team can have a better estimate of story points for similar tasks in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.