7

During the sprint execution, the team should be allowed to change the estimation of a story in the following scenarios.

  1. During execution
  2. When a story is finished
  3. Re-estimate in the absence of the Product Owner(PO)
Improve this question
2
  • 6
    What's the value of re-estimating the story during execution? The estimation doesn't say anything about the actual size of the story, just the expectation.
    – Erik
    Commented Aug 27, 2018 at 10:33
  • Silly question: are we talking about correcting the remaining estimation of a story (usually provided in hours / days) or correcting the original story point estimation of a story? Based on the answers, I assume it's the latter, but it could be interpreted also as the former.
    – Tiago Cardoso
    Commented Nov 5, 2018 at 18:45

7 Answers 7

Reset to default
7

During execution

That's not ideal, but in the real world this happens. And what is the alternative? Not communicate that it might take longer? That's no option. So yes, a story estimation may change during execution. If that happens often, a retrospective why that happens might be in order.

When a story is finished

That's pretty pointless. An estimation is for when the story is not finished. It does have some value to go back to all your finished stories and check whether your estimations were good or where you need to improve, but changing the estimation itself... has no value at that point.

Re-estimate in absence of Product Owner(PO)

No. The whole point of a user-story is communication between the PO and the development team. Doing this communication in absence of one part is simply wrong.

Improve this answer
6
  • If estimates are changed during execution, wouldn't it be the case that all estimates will be nearly correct - which in a real world is far from reality, and in a retrospective will show up without any qualification (that the estimate was revised mid-flight)
    – blispr
    Commented Aug 27, 2018 at 19:08
  • 1
    The estimate is an estimate. It happens before the work begins. To change the estimate once the work has started makes it a fact. If the work did not match the estimate it is something to be learned from (either positively or negatively) once the sprint is complete, during retrospective. This answer does not make this clear and appears to imply that stories can have their estimates changed. Yes, the fact a story will take longer should be communicated well, but if estimates are always updated as the work progresses there is nothing to learn from later.
    – Matt W
    Commented Aug 29, 2018 at 11:10
  • @MattW I'm not sure I can follow you. I did say that a retrospective is needed when estimations change often. But estimations do change. I mean if I say "hey PO, we've got a problem, this will take longer than expected because of X", then the PO will surely want a new estimation based on the new knowledge gained. What would be your alternative? How would the PO be able to react to those changes if we don't have a new estimate? How would we for example determine whether the sprint goal is still reachable?
    – nvoigt
    Commented Aug 29, 2018 at 12:35
  • 1
    Push to get the work done in the sprint. The re-estimation happens at the end of the sprint. If you do think it will take longer than original thought but it can still get done within the sprint, then get it done - discuss afterwards. If you think it can't get done within the sprint any more, discuss whether it is wise to continue with the story at all, or to cancel it. Cancelling may mean it either: doesn't get done at all, gets broken up into smaller stories or gets delayed until a later time. But if you always overwrite the current estimate with a new one, you'll lose metrics.
    – Matt W
    Commented Aug 29, 2018 at 14:35
  • I guess I'm more referring to the record of the estimated points (or whatever you estimate in.) This is the value which should not be overwritten. I'm not saying "never claim a story will take longer than expected" - I'm saying you should mess with the metrics. If it needs re-estimating that should be done at the start of the next sprint, because that is most likely going to involve either breaking the story up a bit or changing it significantly.
    – Matt W
    Commented Aug 29, 2018 at 14:37
4

Once a Sprint is locked down - the estimates are locked, so it is not OK to change an estimate after Sprint Planning is done and the Sprint is locked down. There are a couple of purposes of estimates:

  1. Based on historical trends - allow the Sprint Planning to hit a desired number of points/hours
  2. Tracking the accuracy of the estimators, and constantly providing feedback on their estimates in order to improve the estimates

Basically - do the work upfront on estimates and hold the estimators accountable to improve over time. Or fire them from estimating.

Improve this answer
5
  • Any downside of allowing the team to correct estimation?
    – ssharma
    Commented Aug 27, 2018 at 13:16
  • 1
    (1) You will not be able to assess the quality of the team's ability to estimate (2) Often times the sprint is your contract with your stakeholders - and changing the nature of that for something as short as a sprint is problematic (assuming that your sprints are generally 1-2 weeks). Note that adding new scope to a sprint is different than changing estimates
    – daLegacy
    Commented Aug 27, 2018 at 13:21
  • Sprints aren't locked down, only sprint goals are. Sprint backlog can change whenever that makes sense. And if you fire the team from estimating, then who's going to do the estimating?
    – Erik
    Commented Aug 27, 2018 at 14:15
  • I was being a little tongue in cheek on firing the estimating team. My point is that someone has to enforce the discipline in place for the team and stick to it. Every team varies their implementation to some extent - so at whatever level the estimates are made, I don't see any reason to change them during execution. If you do - this will wreak havoc with things like velocity metrics over time
    – daLegacy
    Commented Aug 27, 2018 at 16:09
  • You seem to cling to a contract rather then collaborate to reach a goal.
    – nvoigt
    Commented Aug 29, 2018 at 12:38
4

All development work includes an element of discovery. A good Scrum team will allow some spare capacity for this, rather than packing a sprint so full that there is no contingency.

Do you need to re-estimate? Well that depends on the circumstances and how much impact the change is likely to have.

If the team discovers that some work is taking longer (or shorter) than expected then there are usually two ways to react:

  • If the impact is small then the team may just carry on as usual.
  • If the impact is significant then the team might need to re-plan and in an extreme situation may need to abort the sprint.

Either way, it may be useful for the team to consider what happened with the estimate at their next retrospective. If there is a consistent problem with estimates (for example, underestimating the time it takes for dependencies) then the team may want to think of ways to address this problem.

Improve this answer
1

If it's during your sprint, you might want to change it if new information comes up. Ideally you bump it and replan, though, if possible, and pull in a story you're more comfortable with the estimate on. If it's not possible: then yes, do it live. Agile is about what works for your team and your customer. If you want to re-estimate in the middle of the sprint and use the new estimate: then go for it. Typically customers are concerned with the work actually getting done, not the estimate, though. If it takes longer than you anticipated: well that's life, but changing the estimate to reflect that doesn't really do much.

You probably wouldn't want to change it after the story has been completed. It's kind of like saying "Well, I guess this task will take 100 hours". Then, if it turns out the task takes 200 hours, you don't go back and say "Oh look, we guessed the task took 200 hours...and it took 200 hours! We're perfect!". No, you guessed it would take 100 hours, and in fact it took double that amount of time. Learn from that mistake, don't pretend it never happened. Your estimates can never get better if you always fudge them to be "perfect" estimates.

Improve this answer
1

Quick answers:

  1. If the story is in progress, but not complete, repointing would be unnecessary. Communicate potential delays immediately, but the points don't help there. The points are used to gauge capacity, and that calculation will already be done by the time the sprint starts.

  2. I would say yes, if the scenario I describe below applies. Otherwise, there's no point.

  3. I don't know that I fully understand what is being proposed here, but don't change points without your PO's knowledge. Capacity is something very important to that role, and changing points unexpectedly will cause unnecessary confusion.

Valid Repointing Scenario

On our engineering teams, we use the Agile Poker Jira app. It's a fantastic solution to synchronous or asynchronous pointing sessions.

I bring it up because one of the great features it provides is showing you some examples of stories that have been assigned specific point values. So if you think a story is going to be 5 points, it will show you some completed 5-point stories to compare to.

Leaving story points uncorrected after a sprint in this case actually contributes to inaccurate pointing moving forward. It impedes your team's ability to appropriately measure their velocity.

As a simple example, if you give a story 2 points, but it ended up being a 5, if you ever have a similar story in your upcoming sprint and you didn't correct the points, you'll overestimate your capacity.

On my teams, if someone feels the story they're working on was improperly estimated, they bring their revised point suggestion to their team for approval. It's quite rare that it happens, and it gets more and more rare as the teams learn.

If you don't compare stories when pointing, then it really doesn't matter. You will just have a wider margin of error on your sprint planning, which means you need to leave a slightly larger buffer in your estimated capacity.

IMO, the pointing process by its nature already has a wide margin of error, and, while that's okay, I still think any simple steps we can do to improve our consistency are worth considering.

Improve this answer
0

Yes, It's always important to communicate with the relevant part of the team that a task will take longer.

I suggest you have some actions when an estimation has changed. For example:

  • Is the sprint goal still achievable?
  • Should the team focus on other tasks given that the current stream of work depended on this one?
  • Inform everyone affected by this (not just the internal team, for example, if it was part of a deliverable for the stakeholders, there should be a way to communicate this changes to them as well.)
  • If it makes sense to do so: log the details of why you needed to change the estimation so it can be used to do better estimates in the future
Improve this answer
0

Estimate in Agile is a measure of complexity and uncertainity (a 5 is somewhere between 3 and 8). Changing the estimate in flight is harmful - your historical estimates should have the same factor of uncertainity and error that current estimates. Comparing estimated backlog size to velocity based on "accurates" is apples to oranges.

When it takes more time just tell - "It takes more time, need to break it down" or something. This is why you have standups. Then next time don't be over optimistic.

At the end of the sprint you should check the estimation accuracy on Sprint level and rhe learn. And underestimating is as bad as overestimating.

Improve this answer

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.