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

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

Expand Messages
  • 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 1 of 5 , Mar 2, 2013
    • 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 2 of 5 , Mar 2, 2013
      • 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 3 of 5 , Mar 2, 2013
        • 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.