During the sprint execution, the team should be allowed to change the estimation of a story in the following scenarios.
- During execution
- When a story is finished
- Re-estimate in the absence of the 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 community
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.
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.
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.
I would say yes, if the scenario I describe below applies. Otherwise, there's no point.
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.
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.