During execution of sprint, should team allowed to change estimation of a story in following scenarios.
- During execution
- When a story is finished
- Re-estimate in absence of Product Owner(PO)
-
5What'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 Aug 27 at 10:33
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.
-
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 Aug 27 at 19:08
-
1The 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 Aug 29 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 Aug 29 at 12:35
-
1Push 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 Aug 29 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 Aug 29 at 14:37
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:
- Based on historical trends - allow the Sprint Planning to hit a desired number of points/hours
- 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.
-
-
(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 Aug 27 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 Aug 27 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 Aug 27 at 16:09
-
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.
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
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.
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.
New contributor
Matt Messersmith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
