How to handle poorly estimated story points during a sprint retrospective?
Hi,
Fairly new to scrum, but my team is trying to figure out how to deal with stories in which we were very inaccurate in estimating our story points (stories that end up being 5+ times more or less than original story point estimation). At our sprint retrospectives we discuss these and try to find the root cause of what caused such a poor estimation to happen, however these stories can be such outliers that it can scew our data to the point that summaries from the sprint are rendered useless. How can we deal with this problem, should we leave the outliers in our data (thereby ruining any accuracy in our velocity charts, etc.) or should do something to change the data to more accurately represent what happened?
Any advice on the issue is appreciated, thanks!
During refinement, was there any indication that these stories were likely to be outliers or were the team confident in making those estimates?
Schuyler, have you tried Agile Estimating 2.0?
https://www.agile42.com/en/blog/2010/04/21/agile-estimating-cheat-sheet/
I have not tried it myself, but the principal sounds like a good practice to get a fairly reliable estimates of story points.
What are the velocity charts used for and by whom?
What is the impact of a velocity that might not be as accurate as it could have been, and how would the team deal with that?
How accurate should be an estimation ?
the story points/velocity are being used to create stability for the team so that can start increasing confidence in predictable delivery, right? i(hopefully it's not just to satisfy a management report
the question for me is "where is the actual problem?" any by that i mean
a. are these stories actually ready to be ingested into the sprint. (DoR met?) or is the team being 'forced' to take them in? (coach team and PO regarding refinement)
b. are there dependencies which the team cannot control? (tricky depending on team/product constellation)
c. are the stories the correct size (coach team on sizing)
d. is the team estimating but then not aligning through the sprint (again refinement)
if the velocity is being used as above the value becomes reduced so a solution is definitely necessary to increase confidence for and in the team. you mention that it has been discussed in the retro but not what the conclusions have been. i rather suspect that it's #a as you say it is a young tram which is not (yet) mature enough for a clean DoR and are taking "dirty" stories into the sprint
Perhaps calculate more slack-time to deal with inaccurate estimations. Moreover, it is also a process of learning by doing, use the refinement sessions to discover why the estimations were off.
I would suggest relative estimation, compare the user story (Complexity/dependency) against the story of similar nature/complexity that were completed (meeting DOD) in the previous sprints
When you estimate a story and you estimate for example 5 story points (the way we do SP is 1 point per day) If you estimated 5 SP, break down that story further during your sprint planning , eg create sub-tasks in the story and estimate these sub-tasks. Generally once you create sub-tasks you either realize this will take longer as we didnt realize how much we had to do or we were bang on in our estimations.
the way we do SP is 1 point per day
Which begs the question - why use story points then? Why not just estimate in # of days, and eliminate the waste present with translating to story points?
I don't intend to be overly-critical, but this is an incorrect application of relative estimation. Story points should have relevance only to each other (i.e. - a "3" is larger than a "2", a "5" is smaller than an "8", etc). Story points should never be associated to a time equivalent.
Also, the creation of sub-tasks does indeed provide the dev team clarity around the story's scope, and there are those who do promote the practice of time-estimating the sub-tasks, but I view sub-task estimation as waste. You already have the relative story point estimate - document the sub-tasks, but there is no need to spend time trying to figure out how long each sub-task should take to complete.