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

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

Expand Messages
  • Sarath Kummamuru
    Hi Ron, 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
    Message 1 of 342 , Jan 1, 2008
      Hi Ron,

      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.
      Where as the second team will claim their velocity to be 3 + 8 + 8 which
      is 19. If you look at the business value delivered both the teams delivered
      the same business value embedded in those three features.

      Only difference is that the first team used smaller numbers with similar
      relative sizing while the second team had a similar relative sizing but used
      bigger numbers.

      Does not mean that the second team is more productive!!! This is
      exactly what I try to coach executive managers when I coach them. It as
      obvious from the long exchange of mails, is very easy to managers to want to
      compare productivities of teams.

      Atleast velocity just as a singular metric doesnot indicate that and
      teams' productivity should not be compared with just velocity in
      perspective.

      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.

      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.

      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.

      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 ;-)

      sarath.


      On Dec 30, 2007 9:09 PM, Ron Jeffries <ronjeffries@...> wrote:

      > Hello, Charlie. On Sunday, December 30, 2007, at 8:27:37 PM, you
      >
      > wrote:
      >
      > >> I'm not convinced of that. Imagine two identical teams in two
      > >> identical universes, working on the same identical product,
      > >> identical etc. The only difference is that one team gets ten
      > >> identical features done per week, and the other gets twenty
      > >> of the same features.
      > >>
      > >> Isn't the second one more productive?
      >
      > > YES! Now if only we had some simple metric that would tell us
      > > that. Ah "velocity" ... that sounds good... can we have it?
      >
      > > I don't believe we have such a measure in velocity.
      >
      > Isn't the velocity of the one team ten, and the other twenty?
      >
      > Ron Jeffries
      > www.XProgramming.com
      > You don't want to sell me waterfall.
      > You want to go home and rethink your life.
      >
      >
      >


      [Non-text portions of this message have been removed]
    • 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, 2008
        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.