How to handle poorly estimated story points during a sprint retrospective?

Last post 01:18 pm May 9, 2018
by Timothy Baffa
9 replies
Author
Messages
12:05 am April 18, 2018

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!

10:49 pm April 18, 2018

During refinement, was there any indication that these stories were likely to be outliers or were the team confident in making those estimates?

02:54 am April 19, 2018

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.

07:10 am April 19, 2018

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?

07:28 am April 19, 2018

How accurate should be an estimation ?

08:34 am April 19, 2018

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

12:39 pm April 19, 2018

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.

02:25 am May 7, 2018

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

04:53 am May 8, 2018

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. 

01:18 pm May 9, 2018

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.