## Re: [XP] Re: What's a good velocity?

Expand Messages
• Hi Kent, ... I found this last sentence really interesting -- it sounds as if you re saying that slack is/can be used to compensate for variance in velocity. I
Message 1 of 55 , May 1, 2009
• 0 Attachment
Hi Kent,

On Fri, May 1, 2009 at 03:58, kentb <kentb@...> wrote:
>
> I think I stand by my statement that predicting and measuring capacity is a
> way to optimize the balance of throughput, latency, and variance. I don't
> understand what you mean by "given a stable velocity, we can influence
> throughput by adjusting wip". To me, velocity and throughput are synonyms.
> Reducing wip can expose variance. Reducing variance can lead to a reduced
> need for slack, and thus higher throughput and/or lower latency.

I found this last sentence really interesting -- it sounds as if
you're saying that slack is/can be used to compensate for variance in
velocity. I hadn't picked up that connection before, but it seems to
have some bearing. Not that I can form a coherent example of its use
on a Friday night... Is this more or less what you meant, and if so,
care to expand?

Thanks,
- Kim
• Hi Dave, Catching up on an old message marked for follow-up... ... Yes, that s what I meant. ... Right, I tried to mention this in the paragraph following the
Message 55 of 55 , May 6, 2009
• 0 Attachment
Hi Dave,

Catching up on an old message marked for follow-up...

On Thu, Apr 30, 2009 at 10:59, davenicolette <dnicolet@...> wrote:
> --- In extremeprogramming@yahoogroups.com, Kim Gräsman <kim.grasman@...> wrote:
>
> This comment of yours caught my eye:
>
>> Another idea I had was to transpose the scale to, say, (10, 20, 40) --
>> because the numbers don't matter -- and assume our velocity would be
>> 70. Then work from that, and try to re-estimate the troublesome fours
>> into somewhere between 20 and 40, some may be 25, some may be 35. This
>> would have made the estimation scale more of a continuum.
>>
>
> I think the notion that "the numbers don't matter" means that there's no absolute "good" or "bad" velocity value.

Yes, that's what I meant.

> The /scale/ might matter, though, because it can influence the team's behavior in a way that may be detrimental.
> When teams use scales like these:
>
> 10, 20, 40
>
> [...]
>
> and so forth, there's a risk of falling into a "false precision" trap. I've seen people get tangled up trying to distinguish between story sizes like 18 vs 24, or 197 vs 202, or 1/4 vs 1/5, or 1.5 vs 1.75. IMHO that's a waste of time and doesn't help with problems like having a "cramped" scale.

Right, I tried to mention this in the paragraph following the one you
quoted. Thanks for expanding.

> Instead of adding trailing zeroes, I'd suggest maybe spreading the scale out a bit. If you're finding that realistic
> story sizes are 1 and 2, why not establish a scale like
>
> 1, 2, 4, 8, Too Big
>
> or
>
> 1, 2, 3, 5, 8, Too Big
>
> and then start calling the "old 2" the "new 4" or the "new 5". That gives you some breathing space without inviting
> debates over falsely-precise sizes.

"Too Big" is nice, I think working that one harder would yield better
predictability.

Thanks,
- Kim
Your message has been successfully submitted and would be delivered to recipients shortly.