Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial Credit for Backlogs
- On Thu, Apr 2, 2009 at 9:27 PM, awible <apwible@...> wrote:
> Choose b.I consistently have hangover, but I drink a lot... ;-)
> The analogy I use in this discussion of hangover is that of earnings per
> 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.
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,And, therefore you don't have a problem. It is also unlikely that you
> 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.
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
> If you can't figure out the issue, I recommend bringing in an outside expertGood idea.
> 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.