What can we do with a "mispointed" story in Scrum?

Question

Is it OK to repoint the story at the beginning of the new sprint to reflect the size that we have now discovered it to be so our velocity is more accurate?

On rare occasions, our team will work a story we thought we broke down into a small, granular story, but it ends up taking the entire sprint and carrying over (it may or may not have an impediment on it). Can we assign a different story-point value to it to reflect the effort it actually took to complete?

As an alternative, can we update the definition of done so that the story can be closed in the current sprint? I understand this is not ideal and could be abused so that everything closes at the end of a sprint, but I am talking about the stories where you know you have gone WAY above the original estimate of points and you don't want your velocity predictor to be skewed.

Answer 1

Software work is not fully predictable

@Péter Török gave you a great answer. However, I would like to disagree with one aspect of what he said, "You accepted a story into the sprint which was not yet understood well enough to be ready for development. You failed to identify in time a significant part of the work to be completed..." He seems to expect that you can fully predict the work during the sprint planning and there should be no surprises. Not really!

Software development, by its very nature, is part R&D and is unpredictable. This is the very reason why we practice Scrum - with its transparency and inspect/adapt cycles.

Here is the relevant extract from the Scrum Guide:

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed.

So, in my opinion:

1. If it happens frequently, do everything that Péter suggested.

2. Exercise adequate due diligence to avoid such surprises. Two of the valuable practices that I can recommend very strongly are - doing a research story to size unfamiliar work and building a proof-of-concept to minimize risk in unpredictable work. If, after doing all that you do run into an issue, as you said on rare occasions, you can re-estimate the remaining work at the beginning of the next sprint, reprioritize and move on.

Answer 2

IMHO debating over whether or not to reestimate the story and how this affects your velocity is treating the symptom instead of the root cause. In the next retrospective (or even earlier, in a dedicated meeting, if this is really such a recurring problem), you should focus on why this occurs, and how to avoid it in the future.

This signals a problem in your backlog grooming and sprint planning process (as you say this happens only rarely, which makes me assume that you do practice backlog grooming in general, nevertheless). You accepted a story into the sprint which was not yet understood well enough to be ready for development. You failed to identify in time a significant part of the work to be completed and now you have a huge story which is too big for the sprint.

Is it OK to repoint the story at the beginning of the new sprint, [...] or update the definition of done so that the story can be closed in the current sprint?

Stories absolutely never should take up an entire sprint. But if you discover this mid-sprint, IMO neither of these options are really good. I think the best is to chop the oversized story up into smaller new stories based on your freshly gained understanding, rather than keeping it in one piece. Then you can reestimate each new story, prioritize them and decide how much you can handle in the current sprint. This is still messy at best, so at this point you may actually want to cancel the sprint in agreement with the PO and start sprint planning anew. It is a drastic measure, for sure. But your sprint is seriously messed up, so it may be better and more in the spirit of Scrum to bring the problem up to the surface and deal with it up front, rather than trying to shove it under the carpet by just readjusting your sprint backlog and pretending everything's back to normal.

Answer 3

TL;DR

This answer focuses less on what to do about improper estimates, and more on why you shouldn't tamper with historical estimates. You ask:

Is it OK to repoint the story at the beginning of the new sprint to reflect the size that we have now discovered it to be so our velocity is more accurate?

The short answer is "no." This is a misunderstanding of what velocity is, and what it's for.

Ret-conning your velocity metrics is a project smell that indicates that velocity is being misused to set management targets, or to somehow justify the team, rather than as a planning tool that measures team capacity.

Leave Inaccurate Story-Point Assignments Alone

Velocity is not a single number. Ideally, velocity is a statistical range over a trailing period. Velocity is useful for estimating overall team capacity, but is not intended as a metric for tracking work-items completed or historical levels of effort.

In addition, velocity implicitly measures the maturity of your estimation process, and should therefore not be retroactively tampered with. For example:

• If you estimate a story at 1 point, but it results in a failed Sprint because it blocked all other stories and was never completed, your points for that Sprint are 0. That is the number that must be averaged with your other Sprint totals to calculate velocity, not the 1 point (or 20 points) that didn't get done.
• If you incorrectly estimate a story at 1 point, throw out 19 other points of work to complete the story on time, and then retroactively assign 20 points to the single story, you haven't really increased your capacity twenty-fold. You need to show that your velocity for that Sprint was 1 rather than 20 so that you can see the impediment in your project burn-down. This also ensures that when you recalculate your trailing average, you reduce your planned Sprint capacity to match your team's current ability to estimate.

Of course, if a story remains undone at the end of a Sprint, it can be re-estimated—hopefully in a more accurate way—during a future Sprint Planning session. That doesn't change the story points it was assigned in a previous Sprint (irrelevant), or the story points it subtracted from your project burn-down (zero). Instead, when it's peeled off the top of the Product Backlog at some point in the future, it will simply be a new estimate for the current Sprint based on what the team knows at that point in time.

Answer 4

TL;DR

Mis-estimates happen. Small variations in the accuracy of your estimates should be expected, and can be absorbed by your process if you aren't over-committing. However, large variations in accuracy or wildly inaccurate estimates are a process problem that should be addressed by the whole Scrum Team, including the Product Owner.

In addition, you may not have a well-articulated Sprint Goal. Managing estimates and backlog items in the absence of a defined Sprint Goal for each Sprint is an exercise in futility. Don't do that.

Identifying Invalid Estimates

A single Sprint Backlog item should never be sized larger than about 2-3 business days. The rule of thumb is that each task on the backlog should be "done" or "not-done" in 1/2 day to 2 days, so you should have a good idea within a couple of days whether a story is on track or not.

During the daily stand-up, stories that are slipping should be identified. In addition, your Sprint Backlog or Kanban board should clearly identify stories in progress that are stuck so that the team can address any impediments.

Scrum, like other methodologies, expects a certain amount of slack in your process to keep flow smooth. A slightly mis-estimated story can usually be absorbed without fuss, but wild miscalculations require more disruptive techniques to manage them.

As an informal rule of thumb, if your Sprint burn-down is out of whack by more than 30%, or if you have a single critical-path story that's more than 50% over estimate, then it's probably worth escalating the matter. Even if the team recovers from the miscalculations during the current Sprint, it should be grist for the mill at your next Sprint Retrospective.

Handling Invalid Estimates

An improperly-estimated story should be identified within 2-6 business days. Allowing a task to slip 200% without triggering some action or awareness within the team would just be silly.

At that point, you should:

1. Determine whether the story is essential to the Sprint Goal.

   If not, discuss pulling it from the current Sprint with the Product Owner. You can do this together so long as it doesn't compromise the Sprint Goal.

2. Re-estimate the task.

   If the story is essential to the Sprint Goal, you should take 10-15 minutes with the team to re-estimate the story to determine if the story can fit within the current Sprint, with or without changes to the Sprint Backlog.

3. Add capacity by trimming other scope.

   If your story is essential, but you have other stories that aren't, the Product Owner can eject the non-essential stories to trim scope. In addition, you may be able to trim scope from a variety of Sprint Backlog items without compromising the Sprint Goal.

4. Request an early termination of the current Sprint.

   If the story is essential to the Sprint Goal, and sufficient scope can't be trimmed to finish the story within the current Sprint, then you should request that the Product Owner call an Early Termination to the Sprint, followed by a Sprint Retrospective and a return to Sprint Planning.

Formally Re-Estimating Unfinished Stories

Any story that is not done by the end of a Sprint is returned to the Product Backlog for disposition by the Product Owner. The Product Owner may de-prioritize or re-scope the story, remove it from the backlog, or may choose to put it back at the top of the Product Backlog for inclusion in the next Sprint.

If the story remains in scope for your next Sprint, then it should be re-estimated and decomposed again during the Spring Planning process, just like any other story. Hopefully, the Scrum Team will have a better handle on it the second time around, and the estimates and decomposed tasks should be more reliable.

If a story makes the rounds a third time, then you have a bigger process problem than a single mis-estimated story. Fix that.