Re: [Scrum] Digest for scrumalliance@googlegroups.com - 24 Messages in 2 Topics

10 views
Skip to first unread message

Scott Duncan

unread,
May 13, 2013, 5:46:21 PM5/13/13
to scruma...@googlegroups.com
At the recent Scrum Gathering, Jeff Sutherland said that, while velocity between teams is not comparable, % increase in velocity is.  He really did not go any further in explaining this, however.  Just wanted to mention this since it happened so recently and so many people heard it.


On Mon, May 13, 2013 at 11:55 AM, <scruma...@googlegroups.com> wrote:

Group: http://groups.google.com/group/scrumalliance/topics

    John Miller <agiles...@gmail.com> May 12 04:39PM -0700  

    Can someone explain how increased velocity is metric we should actually consider for team performance? I keep hearing this and can not but forsee anything but bad consequences from it.
     
    Thank You,
    John
    Sent from my iPhone. It likes to sabotage my grammar.

     

    George Dinwiddie <li...@iDIAcomputing.com> May 12 08:10PM -0400  

    John,
     
    On 5/12/13 7:39 PM, John Miller wrote:
    > Can someone explain how increased velocity is metric we should actually
    > consider for team performance? I keep hearing this and can not but
    > forsee anything but bad consequences from it.
     
    I agree. The easiest way to get increased velocity is to increase the
    estimates (or use smaller stories, if you're calculating velocity by
    counting them). This will give you increased velocity, without any
    increase in productivity.
     
    Often when a team is focused on increased velocity, they try to hurry,
    and they try to eliminate everything that doesn't immediately relate to
    velocity. In this case, usually quality suffers and productivity goes down.
     
    Velocity can go up, in my experience. But it goes up by focusing on
    quality and self-improvement. Clean code allows you to extend it more
    easily. Learning to work better, both individually and as a team, can
    pay dividends in going faster. I've not seen this happen, though, when
    there is an emphasis on velocity.
     
    - George
     
    --
    ----------------------------------------------------------------------
    * George Dinwiddie * http://blog.gdinwiddie.com
    Software Development http://www.idiacomputing.com
    Consultant and Coach http://www.agilemaryland.org
    ----------------------------------------------------------------------

     

    Mark Levison <ma...@mlevison.com> May 12 08:12PM -0400  

    I can double or triple a teams velocity in 5 minutes. However nothing will
    change. Perhaps you had too many of those velocity cocktails last week in
    Vegas :-)
     
    Cheers
    Mark

     

    Ron Jeffries <ronje...@acm.org> May 12 08:15PM -0400  

    Hi John,
     
     
    > Can someone explain how increased velocity is metric we should actually consider for team performance? I keep hearing this and can not but forsee anything but bad consequences from it.
     
     
    It's tricky. Suppose that there is some intrinsic difficulty for stories (relative to some team, software base, etc). So they can produce these stories at some "velocity". Now, if they are working well together, removing impediments, keeping their code clean, building up useful infrastructure, and so on, they'll become more competent, and the software will help them more and more and in fact there's a good shot their velocity will increase.
     
    Thing is, if you ASK for this, they'll try to go fast, won't work well together, won't remove impediments, won't keep their code clean, will build up crappy infrastructure and everything goes to hell.
     
    Neat, huh? You can only get it if you don't want it.
     
    Ron Jeffries
    www.XProgramming.com
    Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better.
    Of course you might plummet to the earth and die, but probably not: you were made for this.

     

    "Kurt Häusler" <kurt.h...@gmail.com> May 13 05:43AM +0200  

    Does measuring velocity in terms of number of PBIs rather than number of Story Points also suffer from the same bad consequences?
     
     

     

    John Miller <agiles...@gmail.com> May 12 08:48PM -0700  

    I would think so. I can chop up the size of PBI's to make it appear I increased velocity. I can expect increased velocity as a manager and change behavior to getting more done rather than the right thing done. What are your thoughts, Kurt?
     
    Thank You,
    John
    Sent from my iPhone. It likes to sabotage my grammar.
     
     

     

    Alan Dayley <ada...@gmail.com> May 12 09:37PM -0700  

    When we want a car to increase velocity we do not reach inside the dash and
    turn the speedometer needle, we press on the accelerator. We don't think
    about all the stuff it takes to get the added pressure on the accelerator
    pedal to result in an increased empirical measurement at the speedometer.
     
    A few important things about the car going faster:
    - All the stuff that causes the increase in velocity is complex but well
    understood and predictable.
    - The pressure on the accelerator causes various inputs into the engine to
    change in the desired direction.
    - The velocity is the outcome of those inputs. Change the inputs and the
    outcome changes.
     
    Unlike a complex engine, teams and organizations are made up
    of independently acting agents, creating emergent and unpredictable
    behavior. We can't predict with certainly the effect on velocity of any one
    input. We have to learn over time and experimentation what is working. And
    what is working and even improving today will not work forever. There are
    just too many influences, even completely outside the team's organization,
    that can change the outcome. Thus the need for Agile ideas and agility.
     
    The velocity (amount of work done) of a team is effected by various inputs.
    It is the outcome of those various inputs. Attempting to change the
    velocity directly bypasses the engine (the team capabilities) and all the
    inputs. The inputs are the same, the team capabilities haven't improved. In
    just asking for the needle to be moved directly, you have bypassed the path
    to viable capability improvement. And the value of velocity as an empirical
    indicator for planning is ruined.
     
    Don't ask to increase velocity. Ask what inputs (priority, vision, clarity
    of purpose, customer delighters, individual and team autonomy, environments
    supporting collaboration, organizational structures that foster trust,
    etc., etc.) you can change so that your team (the engine) can improve.
     
    And, if I may, some more of my recent comments about this:
    http://www.bigvisible.com/2013/03/agile-transformation-faster-not-magical/
     
    Alan
     
     
     
     
     
     

     

    "Kurt Häusler" <kurt.h...@gmail.com> May 13 09:28AM +0200  

    > I would think so. I can chop up the size of PBI's to make it appear I increased velocity.
     
    That doesn't sound too bad.
     
    > I can expect increased velocity as a manager and change behavior to getting more done rather than the right thing done. What are your thoughts, Kurt?
     
    Well I consider how the Kanban community talks about throughput, which
    essentially velocity measured in items (or perhaps in money). It is
    hard to game. It is hard to increase directly, but if our customer is
    more interested in features in aggregate, or quantity of features
    rather than speed to market if a single feature, optimizing throughput
    might be a worthy goal. You can run experiments, and determine if they
    are worthwhile or not by measuring increases in throughput.
     
    If you have a backlog and you know that if you cannot deliver n
    stories before the end of the year then the operation isn't viable,
    otherwise you should shut up shop now. If you see throughput or
    velocity as something that cannot or should not be optimized and you
    know with your current velocity you won't reach it then what do you
    do? If you assume it is hard but possible to change you might consider
    the risks of e.g. hiring someone to add capacity. I think the same
    thinking can be applied to teams using Scrum, to a certain extent,
    with caution of course.

     

    "Kurt Häusler" <kurt.h...@gmail.com> May 13 09:33AM +0200  

    In short I think we can reduce velocity (not story points but true
    velocity in number of items or actual value) by reducing waste, using
    improved techniques, (making items smaller is a pseudo-gamey way of
    doing it that still brings advantages), adding capacity, investing in
    learning etc.
     

     

    Ron Jeffries <ronje...@acm.org> May 13 04:19AM -0400  

    Kurt,
     
     
    > Does measuring velocity in terms of number of PBIs rather than number of Story Points also suffer from the same bad consequences?
     
     
    Can you think of some reason why it wouldn't? What has been your experience when a team was pressured to take on more items?
     
    Ron Jeffries
    www.XProgramming.com Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

     

    Ron Jeffries <ronje...@acm.org> May 13 04:22AM -0400  

    Hi Kurt,
     
     
    > On Mon, May 13, 2013 at 5:48 AM, John Miller <agiles...@gmail.com> wrote:
    >> I would think so. I can chop up the size of PBI's to make it appear I increased velocity.
     
    > That doesn't sound too bad.
     
     
    Yes. We did two stories last time. This time we cut them in half and did FOUR! Twice as fast! We rock! :)
     
    Ron Jeffries
    www.XProgramming.com
    If another does not intend offense, it is wrong for me to seek it;
    if another does indeed intend offense, it is foolish for me to permit it.
    -- Kelly Easterley

     

    George Dinwiddie <li...@iDIAcomputing.com> May 13 09:11AM -0400  

    John,
     
    On 5/12/13 11:48 PM, John Miller wrote:
    > I would think so. I can chop up the size of PBI's to make it appear I
    > increased velocity.
     
    With this, at least you've got the advantage of small stories (assuming
    they remain functional slices).
     
    > I can expect increased velocity as a manager and
    > change behavior to getting more done rather than the right thing
    > done. What are your thoughts, Kurt?
     
    Hmmm... I hadn't imagined doing the wrong things.
     
    Any judgmental approach is likely to backfire, whether using "objective
    numbers" to back it up or not. My advice is to seek understanding.
     
    - George
     
     
    --
    ----------------------------------------------------------------------
    * George Dinwiddie * http://blog.gdinwiddie.com
    Software Development http://www.idiacomputing.com
    Consultant and Coach http://www.agilemaryland.org
    ----------------------------------------------------------------------

     

    Dan Rawsthorne <dan.raw...@drdansplace.com> May 13 06:34AM -0700  

    Just so. Velocity is a result, not a goal. You'd like to know your
    team's velocity so you can do adequate predictions, but you can't set a
    goal of a given velocity in order to get the predictions you want.
    Dan Rawsthorne, PhD, PMP, CST
    3Back.com <http://www.3Back.com>
    1-855-32-3BACK x323
    Author of /Exploring Scrum: the Fundamentals/
    <http://www.amazon.com/dp/1461160286>
    On 5/12/2013 5:15 PM, Ron Jeffries wrote:

     

    Amitai Schlair <sch...@schmonz.com> May 12 10:18PM -0400  

    On Sun, May 12, 2013 at 8:10 PM, George Dinwiddie
    > it more easily. Learning to work better, both individually and as
    > a team, can pay dividends in going faster. I've not seen this happen,
    > though, when there is an emphasis on velocity.
     
    This is a case of the old adage "Be careful what you measure, because
    you'll get it." Whether we want them to or not, metrics encourage
    people to maximize them. It's a rare metric that encourages its own
    maximization in the ways you'd want. Velocity isn't one of those, it's
    just a really useful indicator, so we have to live with it until a
    better one comes along, and in the meantime try our best to prevent
    people from doing wrong things with it.
     
    Like Ron and George are saying, if we confuse the map for the
    territory, we won't get somewhere real any faster.

     

    John Miller <agiles...@gmail.com> May 13 08:57AM -0700  

    Hi Kurt,
     
    I agree with smaller than larger PBI's.
    Not so sure about throughput being harder to game or a better metric than velocity. CFD's just makes it look more scientific.
     
    The reason I asked the question in the first place is I keep hearing not only practitioners state the need to measure and increase velocity, but articles staring how coaches helped increase velocity, as well as hearing practitioners stating how a coach or trainer suggested it as an improvement metric. I have always thought it was dangerous, but open to changing my mind if I heard a good argument for it.
     
     
    Thank You,
    John
    Sent from my iPhone. It likes to sabotage my grammar.
     
     

     

    George Dinwiddie <li...@iDIAcomputing.com> May 13 12:22PM -0400  

    John,
     
    On 5/13/13 11:57 AM, John Miller wrote:
    > suggested it as an improvement metric. I have always thought it was
    > dangerous, but open to changing my mind if I heard a good argument
    > for it.
     
    Calling someone a coach doesn't make them one.
     
    - George
     
    --
    ----------------------------------------------------------------------
    * George Dinwiddie * http://blog.gdinwiddie.com
    Software Development http://www.idiacomputing.com
    Consultant and Coach http://www.agilemaryland.org
    ----------------------------------------------------------------------

     

    Jesper S <jes...@stockenstrand.com> May 13 05:02AM -0700  

    I would like some hints in how to handle vacation times. We are a small
    team and the coming Sprint one team member will be on vacation and one team
    member will be working part time outside the team, actually he will have to
    be away on the first day of the Sprint, thus missing the Sprint planning.
    With just one full time team member left how should I handle Sprint
    planning? Should I postpone the meeting one day?
     
    /Jesper

     

    Ron Jeffries <ronje...@acm.org> May 13 11:01AM -0400  

    Hi Jesper,
     
     
    > I would like some hints in how to handle vacation times. We are a small team and the coming Sprint one team member will be on vacation and one team member will be working part time outside the team, actually he will have to be away on the first day of the Sprint, thus missing the Sprint planning. With just one full time team member left how should I handle Sprint planning? Should I postpone the meeting one day?
     
     
    I believe I would postpone it, since it's just one day. Try it, see what happens.
     
    Ron Jeffries
    www.XProgramming.com
    I have two cats, and a big house full of cat stuff.
    The cats fight and divide up the house, messing up their own lives.
    Nice work cats.
    Meow.

     

    John Miller <agiles...@gmail.com> May 13 08:23AM -0700  

    Yes. I recommend keeping your sprint review date as is, though.
     
    Thank You,
    John
    Sent from my iPhone. It likes to sabotage my grammar.
     
     

     

You received this message because you are subscribed to the Google Group scrumalliance.
You can post via email.
To unsubscribe from this group, send an empty message.
For more options, visit this group.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

John Miller

unread,
May 13, 2013, 5:49:25 PM5/13/13
to Scrum Alliance - transforming the world of work.
Just because you can compare does not mean you should.
John Miller

Amitai Schlair

unread,
May 13, 2013, 6:10:30 PM5/13/13
to scruma...@googlegroups.com
On Monday, May 13, 2013 5:46:21 PM UTC-4, scott.duncan wrote:

At the recent Scrum Gathering, Jeff Sutherland said that, while velocity between teams is not comparable, % increase in velocity is.  He really did not go any further in explaining this, however.  Just wanted to mention this since it happened so recently and so many people heard it.

It makes sense that comparing velocity between teams is meaningless. Points are meaningless. When teams are reasonably internally consistent about the relative size of stories over time, points have a useful meaning to that team. (And to the extent that their product backlog has the right stories on it, and they've assigned the right point values, and working conditions hold, extrapolating from those points can be useful to stakeholders with schedules.)

It sort of makes sense, at least mathematically, that change in velocity could be compared across teams. But why would you want to? I suppose if you're an executive doing some sort of sadistic experiment about working conditions, you'd want to compare how much better or worse each of your subjects gets. But that experiment is probably unnecessary, since we all have a pretty good idea what good working conditions look like. When else would it be worth making such a comparison?

I was also confused by Jeff's claim that since we can usually expect some amount of interruption, it's worth putting a corresponding buffer story into the sprint. How big should the buffer be? If it's roughly the same each sprint, our velocity already accounts for it, so what's the marginal benefit of the buffer story? If it's different each sprint, how can we possibly know what it should be? And even if the interruption-buffer can be predicted and does add some value, it also has a cost: people confuse identified persistent problems for unsolvable problems. Learned helplessness. We may find ourselves making less effort to reduce the number of interrupts because the problem has been given a name that we see every sprint and sigh at.

Am I missing something? Did anyone understand this idea of Jeff's differently?

Ron Jeffries

unread,
May 13, 2013, 6:26:40 PM5/13/13
to scruma...@googlegroups.com
Hi Amitai,

On May 13, 2013, at 6:10 PM, Amitai Schlair <sch...@schmonz.com> wrote:

I was also confused by Jeff's claim that since we can usually expect some amount of interruption, it's worth putting a corresponding buffer story into the sprint. How big should the buffer be? If it's roughly the same each sprint, our velocity already accounts for it, so what's the marginal benefit of the buffer story? If it's different each sprint, how can we possibly know what it should be? And even if the interruption-buffer can be predicted and does add some value, it also has a cost: people confuse identified persistent problems for unsolvable problems. Learned helplessness. We may find ourselves making less effort to reduce the number of interrupts because the problem has been given a name that we see every sprint and sigh at.

Am I missing something? Did anyone understand this idea of Jeff's differently?

Suppose that there is such a thing as velocity and that ours is nine or ten consistently. If we always select ten, we'll fail half the time and that may feel bad. And depending how we work, we might risk more than one if interruptions go up, winding up with 10 stories all 95% done == zero.

If we select nine, we'll be wasting half a story every Sprint, or making random decisions about what to do at the last minute.

So, one could argue, we select nine, plus one "if we have time". This could be a decent way for some teams to deal with the situation. When we get the buffer one done we feel good, and no one feels bad if we don't.

It's all kind of a game, to me, and if a team needs to do this I'd want to look into why. But given that it's a game, I think I understand it.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

Alan Dayley

unread,
May 13, 2013, 6:29:35 PM5/13/13
to scruma...@googlegroups.com
"...people confuse identified persistent problems for unsolvable problems."

Nice! I'm tweeting that one.

Alan



--

Daniel James Gullo

unread,
May 13, 2013, 6:41:15 PM5/13/13
to scruma...@googlegroups.com
+1  A particular team may only be capable of achieving a certain level of change.  So, even comparing their percentage if increase with other teams isn't really a morale-building practice.  I would go so far as to say that comparing them to their own previous numbers is not the goal here either. Making THAT their goal instead of shippable software defeats the purpose.  Goodhart's law still applies.


"How can I make a difference so that I may bring peace to this world that I love and cherish so much?" - Gandhi

Amitai Schlair

unread,
May 13, 2013, 7:20:44 PM5/13/13
to scruma...@googlegroups.com
On Monday, May 13, 2013 6:29:35 PM UTC-4, alandd wrote:

"...people confuse identified persistent problems for unsolvable problems."

Nice! I'm tweeting that one.
 
Glad you liked. Thanks for making a new guy feel welcome! As it happens, that sentence began life as a tweet: https://twitter.com/schmonz/status/331460754668654592

Ron, you've put a finger on what felt off to me. If my team wants to futz with buffer stories as a matter of course, I don't necessarily think we're wrong to want that, but I definitely first want to talk about why.
Reply all
Reply to author
Forward
0 new messages