Thoughts on re-estimating stories committed in the sprint, and additional tickets
Hello, recently I just joined a team that have been using story points and noticed that at the end of every sprint (prior to closing the sprint in JIRA), they would look at the outliers in the control chart and re-estimate their story point estimates. for example, if a 1pt story turned out to be more like a 5pt story, they would change it to 5. their reasoning behind it is so that the resulting velocity of the team would be more accurate (in terms of using it in the next sprint planning).
my initial thought about re-estimating it is that it has no value.. since I would rather talk about why it turned out to be a 5, then document the misses/things that should be considered in either the definition of done, or discuss it in retro to determine process improvements.
In terms of updating it for planning purposes, I would think that it'll be more accurate to plan using the team's velocity (with underestimated completed stories) since that would mean that our target velocity for the upcoming sprint would be lower and more realistic. I think that we somehow need a way to show that our estimates are getting better.. or am I wrong?
_________________________________________
Additional question - if the team identified that there are additional tickets that need to be added in the sprint to achieve the sprint goal, do you still give story point estimates to those tickets?
I'd agree with you that reestimating doesn't add value. The estimate itself loses (nearly) all value once it's selected for a Sprint. It could be worth using outliers for discussion points in the Sprint Retrospective, but an even better approach would likely involve moving away from estimates and onto cycle time and throughput and either talking about ways to further decompose work into valuable increments or talking about the outliers and how to be more efficient at moving them through the workflow. Talking about estimates, especially points, consumes a lot more time than the value of those estimates have for a team, so moving away from them can help the team focus on more valuable activities like refinement (primarily slicing and ordering) or the delivery work. And once you get here, your point about work discovered in the middle of a Sprint becomes a moot point.
for example, if a 1pt story turned out to be more like a 5pt story, they would change it to 5. their reasoning behind it is so that the resulting velocity of the team would be more accurate (in terms of using it in the next sprint planning).
This so-called "accuracy" won't add up to a hill of beans unless lessons are learned and applied. What are they going to do differently in the next Sprint, in terms of estimating how much work they can take on to meet a good Sprint Goal?
If suitable lessons are not drawn, all they're doing is fiddling the books to mask an ongoing weakness in estimation, making things look better. They're covering a problem up so history matches whatever ends up being accomplished, and transparency over the ability to forecast is thus compromised.
An estimate is a guess made at a specific point in time based upon the information that is available. When they change their estimates after the work is done, it is no longer an estimate. It is using actual data to provide data. Comparing estimates to actuals is like comparing dogs to cows. There is nothing that can be learned from the exercise.
The team has already shown a tendency of trusting actuals over estimates. So, @Thomas' suggestion of using flow metrics (throughput, cycle time) should appeal to them. In fact, you can use those metrics to plan for a Sprint. If history shows that a 2 week Sprint has throughput of 6 items, then take that into account when picking the Sprint Backlog. In the end, it will probably be more accurate.
I like @Ian's comment.
This so-called "accuracy" won't add up to a hill of beans unless lessons are learned and applied.
Just changing the number does nothing to improve. Learning why their estimate did not align with the actual work is the most valuable thing. That allows them to adapt their estimation techniques to be more useful. Think of it in terms of fuel. If you estimate that it will take 8 liters of gasoline to drive your car to a meeting place and you found yourself sitting on the side of the road with no gasoline, you aren't going to help yourself in the future if you don't determine why your estimate was wrong.