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

Re: [XP] Don't let them see our velocity?

Expand Messages
  • Ron Jeffries
    Hello, Sarath. On Tuesday, January 1, 2008, at 2:08:50 PM, you ... Yes, if we make the numbers different enough we can prove anything. Nonetheless, my point
    Message 1 of 342 , Jan 1, 2008
    • 0 Attachment
      Hello, Sarath. On Tuesday, January 1, 2008, at 2:08:50 PM, you
      wrote:

      > I some how seem to differ about these two teams and what they project
      > about their velocities.

      > Say we have a back log of Stories A through J (say 10 stories).

      > When the teams are story pointing these on team could have numbers like

      > 2,5,5,5,3,5,1,5,3,2.

      > But the other teams could have their story point estimates (with similar
      > relativity) as

      > 3,8,8,8,5,8,2,8,5,3.

      > With this situation both teams cold be completing user stories A, B, C in
      > the one iteration. Then the first team will claim their velocity to be 2 + 5
      > + 5 = 12 SP per Iteration.

      > ...

      Yes, if we make the numbers different enough we can prove anything.

      Nonetheless, my point is that hidden inside velocity, when we factor
      out all the gummi bears and whatever, there is a clue about real
      productivity.

      We can pretend there isn't, but I don't think a manager is going to
      believe us ... and I think he is right not to. Velocity is a not
      very complex encryption of the number of stories, including:

      - possibly flawed estimates of difficulty;
      - multiplication by some weird constant;
      - variability in time;
      - probably other stuff;

      but it's still just counting stories, multiplied by these odd
      numbers. I feel that all this resistance to comparing them is
      trying to hold back the tide. I think it is the case that

      - different teams really are differently productive;
      - managers want to know about this;
      - velocity is enough like that to be tempting.

      If we can figure something better, they'll use it. As has been
      pointed out, forced rankings are pernicious anyway, but we would
      probably do better with a meaningful number ... if we can devise
      one.

      > But then why is velocity important for the external world. I do strongly
      > believe (like Ron) that velocity should be published and should be available
      > to outsiders it is not just an internal metric. When you combine the
      > Velocity and the Product Back Log size (sum of estimates of the items in the
      > product back log) it gives a very strong picture of where the team stands
      > with the release commitments.

      Yes ... there's something in there that should be of use ...

      > Velocity is important and critical in this context for people outside
      > the team and if a CxO wants to check where we stand in the context of
      > customer commitments this is the metric in the context of the Product back
      > log size that is critical.

      ... though this could be a burn chart for the team, certainly NOT an
      individual velocity number.

      > Velocity changes (esp over multiple iterations) give a very strong feel
      > for how the project is going. When we plot the velocity in the product burn
      > down chart there is so much a manager or a CxO can infer about the way the
      > project is going on, the way the team is responding to customer changes, and
      > how volatile the product definition itself is.

      Yes ...

      > So i strongly tell teams to publish their velocities and the Release
      > burndown charts (The whole idea of agile is openness and these few artifacts
      > that we have are immense information disseminators and to hold them back
      > would be a criminal waste. As a team we might be losing an opportunity for a
      > CIO or CEO to possibly suggest changes, corrections or if things are going
      > commend the team).

      > So I do believe velocity is an external metric (of the small set of
      > Agile metrics I Strongly believe all of them are external metrics that are
      > expected to be displayed openly to the world!!!) Which is why i am a strong
      > advocate of Story boards, Task boards, burn down charts on boards, etc.

      > Would like to hear feed back. Guess it is a pretty long mail. Sorry for
      > assuming patience from the group to read it ;-)

      Like a lot of other people here, I'm fearful that velocity will be
      misused. I'm trying to want to fix it so that we don't have to be
      afraid of it, rather than try to argue it out of existence.

      Ron Jeffries
      www.XProgramming.com
      If not now, when? -- The Talmud
    • Ron Jeffries
      Hello, Ilja. On Saturday, February 16, 2008, at 6:23:42 PM, you ... Well, it sounds like it would take a pretty narrow set of ideas on how to improve
      Message 342 of 342 , Feb 16 5:33 PM
      • 0 Attachment
        Hello, Ilja. On Saturday, February 16, 2008, at 6:23:42 PM, you
        wrote:

        > I expect this to increase our velocity in the middle run. And I'm all
        > for measuring it.

        > I doubt we would have even tried this event if we had focused on
        > improving velocity.

        > How does that sound to you?

        Well, it sounds like it would take a pretty narrow set of ideas on
        how to improve velocity. In a discussion on that, I would hope that
        ideas like learning, better tools, higher morale, and better
        communication would come up.

        Ron Jeffries
        www.XProgramming.com
        Anyone can make the simple complicated.
        Creativity is making the complicated simple. -- Charles Mingus
      Your message has been successfully submitted and would be delivered to recipients shortly.