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

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

Expand Messages
  • Doug Sims
    Just started with a team that I am new to, but they have been together for awhile. Background: When Planning, each story is given a story estimate based on
    Message 1 of 5 , Mar 1 11:49 AM
    • 0 Attachment

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


      Background:

      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?

      Cheers,

      Doug Sims

           

    • Alan Dayley
      A very short answer: In a Sprint the team is agreeing to complete the stories, not the tasks. As the team works on a story they may find that some tasks are
      Message 2 of 5 , Mar 1 12:51 PM
      • 0 Attachment
        A very short answer:

        In a Sprint the team is agreeing to complete the stories, not the tasks. As the team works on a story they may find that some tasks are not needed or some tasks were not known during Sprint planning. That is OK, tasks come and go, the stories get done.

        If your story estimates are tied to task estimates in some way, completing tasks tends to become the focus and changing tasks, even when needed, is discouraged. Since tasks are not the point, working product is the point, decouple the tasks from the stories as much as possible and get the stories done.

        (Narwhals? You mean like the aquatic mammal with a horn? I've never hear of such a sizing method.)

        Alan



        On Fri, Mar 1, 2013 at 12:49 PM, Doug Sims <doug.sims@...> wrote:
         

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


        Background:

        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?

        Cheers,

        Doug Sims

             


      • avinap77
        Hi Doug, ... Story estimates are used by the PO to plan releases (long term planning). Task estimates are used by the dev-team to plan their day-to-day work
        Message 3 of 5 , Mar 2 12:25 AM
        • 0 Attachment
          Hi Doug,

          --- Doug Sims <doug.sims@...> wrote:
          > I can see that "story" estimates of 3, 5 and 8 may have taken
          > anywhere from 3 to 20+ narwhals to actually complete.
          > (...)
          > What am I missing here?


          Story estimates are used by the PO to plan releases (long term planning).
          Task estimates are used by the dev-team to plan their day-to-day work towards the end of the sprint (short-term planning).

          None of these are supposed to be used to track actuals (past). They are just tools to help planning ahead (future).

          Might this shed your problem in a different perspective?

          HTH,
          Avi
        • Ron Jeffries
          Hi Avi, ... Long-term planning is risky business for a process focused on steering based on the current real situation, as it calls the shot for those who
          Message 4 of 5 , Mar 2 3:07 AM
          • 0 Attachment
            Hi Avi,

            On Mar 2, 2013, at 3:25 AM, "avinap77" <avi.naparstek@...> wrote:

            Story estimates are used by the PO to plan releases (long term planning).

            Long-term planning is risky business for a process focused on steering based on the current real situation, as it "calls the shot" for those who read the plan, and therefore makes it dangerous for the Product Owner to change plans, as it invites questions.

            Task estimates are used by the dev-team to plan their day-to-day work towards the end of the sprint (short-term planning).

            If a team wanted to do this, then under the principle of self-organization, it should be allowed. It would surprise me to find a team that found it useful, much less a team who actually wanted to do it. 

            If a team did choose to do it, then one might think that estimates should be made during the Sprint, when there is more information, rather than at the beginning.

            None of these are supposed to be used to track actuals (past). They are just tools to help planning ahead (future).

            And yet many teams do compare estimates and actuals. This is usually pernicious, because it drives estimates upward.

            Ron Jeffries
            If it is more than you need, it is waste. -- Andy Seidl

          • avinap77
            Hi Ron, ... Agreed, yet that (release planning) is still the purpose of story estimates. I would expect a healthy scrum organizatin to allow the PO to plan
            Message 5 of 5 , Mar 2 9:49 AM
            • 0 Attachment
              Hi Ron,

              --- Ron Jeffries <ronjeffries@...> wrote:
              > > Story estimates are used by the PO to plan releases (long term
              > > planning).
              >
              > Long-term planning is risky business for a process focused on
              > steering based on the current real situation, as it "calls the shot"
              > for those who read the plan, and therefore makes it dangerous for
              > the Product Owner to change plans, as it invites questions.

              Agreed, yet that (release planning) is still the purpose of story estimates.

              I would expect a healthy scrum organizatin to allow the PO to plan without making "inviting questions" become a dangerous thing, but a constructive thing instead. This is probably fodder for a seperate thread, though.


              >
              > > Task estimates are used by the dev-team to plan their day-to-day
              > > work towards the end of the sprint (short-term planning).
              >
              > If a team wanted to do this, then under the principle of self-
              > organization, it should be allowed. It would surprise me to find a
              > team that found it useful, much less a team who actually wanted to
              > do it.
              >

              I'd be glad to surprise you, I've worked with several teams that found this very helpful.
              This does not mean it is always helpful - I've also worked with teams in situations where the estimates were just pulling them back.
              Context matters.

              And again, all this is probably irrelevant to the current thread...


              > If a team did choose to do it, then one might think that estimates
              > should be made during the Sprint, when there is more information,
              > rather than at the beginning.

              FWIW I agree with you - I find too that this task-level estimation works best when refined day by day throughout the sprint. Just making initial estimates at the sprint planning has some limited benefits, but they wear off quickly if it stops at that point.

              I find the initial task estimates help make an educated guess about if a story is too big to fit in a sprint (or heaven forbid, too small), and helps the team flesh out an initial solution and grasp of the PBI's complexity. Again, the value of having this upfront (during sprint planning) is mainly so they can commit/forecast based on their expected capacity for the sprint.


              > >
              > > None of these are supposed to be used to track actuals (past).
              > > They are just tools to help planning ahead (future).
              >
              >
              > And yet many teams do compare estimates and actuals. This is usually
              > pernicious, because it drives estimates upward.
              >

              Agreed. and a sad thing IMHO.



              Best wishes, good to correspond again after such a long time.
              Avi
            Your message has been successfully submitted and would be delivered to recipients shortly.