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)
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this communityDuring execution of sprint, should team allowed to change estimation of a story in following scenarios.
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.
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:
Basically - do the work upfront on estimates and hold the estimators accountable to improve over time. Or fire them from estimating.
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:
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:
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.