Loading ...
Sorry, an error occurred while loading the content.

56654Can someone explain the benefit to de-coupled story and task estimates?

Expand Messages
  • Doug Sims
    Mar 1, 2013
    • 0 Attachment

      Just started with a team that I am new to, but they have been together for awhile. 


      When Planning, each story is given a "story" estimate based on (perceived) size and complexity. The scale for this is based on Fibonacci and almost every story seems to get a "3" or "5" with an occasional "8". This team is good about breaking anything larger into multiple stories. The team then adds tasks under these stories which are estimated in "narwhals". The "story" points are used in velocity/capacity/sprint planning but the daily burndown is displayed in task ("narwhal") estimates and completed.

      On a side note, the tool we are using isn't effective in providing me or the team much prior velocity tracking  on earlier sprints primarily due a bad habit I hope to break on this team - a lot of issues being moved forward in the past and no good way of telling what moved where. What I do have is the most recent sprint data (both "story" estimates and "narwhal" actuals). 

      When I go into the story details from the sprint, I can see that "story" estimates of 3, 5 and 8 may have taken anywhere from 3 to 20+ narwhals to actually complete. The team completed stories worth 36 "story" estimate points and logged completed tasks worth 75 narwhals. 

      I have worked with quite a few teams in the past and used different strategies from tracking hours, points or what not, but we have always burned-down and sprint planned using the same scale. Before I bring this up in our retrospective, I wanted to get a better handle on what the expected advantages of having a separate scale may be, as to me it adds complexity and appears to be a less reliable metric.     

      Using the  Fibonacci is working well for the team to prevent large or ambiguous stories from making the sprint so I do see great value in using it for that purpose. What I fail to understand is why you would want to use the Fibonacci values for sprint planning capacity rather than the number of task estimate points ("narwhals") the team has been completing on prior recent sprints. What am I missing here?


      Doug Sims


    • Show all 5 messages in this topic