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

Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial Credit for Backlogs

Expand Messages
  • Adam Sroka
    ... I consistently have hangover, but I drink a lot... ;-) The goals of the planning process are: 1) to come to a shared understanding of what needs to be done
    Message 1 of 17 , Apr 2 10:12 PM
      On Thu, Apr 2, 2009 at 9:27 PM, awible <apwible@...> wrote:
      > Choose b.
      > The analogy I use in this discussion of hangover is that of earnings per
      > share.
      > A public company that is 90% complete in closing a deal at the end of Q1,
      > cannot claim any portion of the revenue from that deal. If they finally
      > complete the deal in Q2, they claim the revenue then. Do they adjust their
      > expectations up for Q2 given this understanding? No. Why? Because - at the
      > end of Q2, they're likely to have incomplete deals as well, which will
      > offset the positive impact of the hangover.
      > And so it goes. It all evens out. Just like iteration points.
      > And by all means, have more stories on deck to slide into the iteration if
      > the team hits on all cylinders in the next iteration.
      > There's another smell here though... if you consistently have hangover, then
      > something is amiss. Perhaps your stories are too big or poorly conceived (a
      > common problem), or your planned velocity (commitment) is too high.

      I consistently have hangover, but I drink a lot... ;-)

      The goals of the planning process are: 1) to come to a shared
      understanding of what needs to be done and what will be done in the
      current iteration. 2) to give the business a way to understand how
      much can be done in a given period and/or approximately when a certain
      set of features will be complete. These goals are not well served by a
      process that allows work to bleed across sprint boundaries.

      The point behind allowing partial stories to "disappear" rather than
      "hangover" is that apparent velocity decreases leading to more
      conservative commitments that are more likely to be met. Thus the
      process should adjust to the actual capabilities of the team.

      > I'm currently working on a team on which hangover is rare; when it occurs,
      > it is usually due to some exigent factor (e.g. dependency/commitment not
      > being met by another team). If not, it usually gets done in day one of the
      > next iteration.

      And, therefore you don't have a problem. It is also unlikely that you
      would have asked the question. The advice that I am giving is designed
      to help people who frequently (Or at least occasionally) face this
      problem. Slowing down is likely to help in the short term.

      > That said, I've seen teams with massive hangover.

      Probably because of a) poor estimation, b) over commitment, and/or c)
      lack of communication (i.e. poorly understood requirements.) Lowering
      the velocity is likely to help with both a and b. If c isn't detected
      and dealt with the process will break down and the team will grind to
      a halt, but estimation isn't the problem and no estimation strategy
      will help.

      > If you can't figure out the issue, I recommend bringing in an outside expert
      > to help facilitate/diagnose. In particular, find someone who has actually
      > participated in many teams in many environments and who has seen many
      > problems. That is - don't find a theoretical agilist with PowerPoint at the
      > ready... use a practiced one with post-its, markers, flipcharts, stories,
      > analogies and enthusiasm.

      Good idea.
    Your message has been successfully submitted and would be delivered to recipients shortly.