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

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

Expand Messages
  • Steve Howell
    ... You could use number of code-checkins/per week. If it s the team s job to change the codebase to add features, then code-checkins is a fairly direct
    Message 1 of 342 , Jan 1, 2008
      --- Ron Jeffries <ronjeffries@...> wrote:

      > Hello, John. On Tuesday, January 1, 2008, at
      > 12:07:26 PM, you
      > wrote:
      >
      > > Whose productivity?
      >
      > > A bit farther down in the thread you give several
      > rather
      > > different spans, including:
      >
      > > 1. from when a feature is proposed to when it's
      > put into
      > > production use.
      >
      > > 2. when the feature is added to the dev team's
      > workload
      > > to when it's delivered.
      >
      > > 3. when the dev team starts working on it to when
      > they
      > > deliver it at the end of the iteration. This is
      > what I normally
      > > think of as a cycle - it's the iteration.
      >
      > > The only one that directly relates to the
      > development
      > > team's productivity is number 3. The other two
      > relate
      > > only to the extent that the development team is
      > the
      > > bottleneck in the overall process, which may or
      > may
      > > not be true.
      >
      > Yes, I agree with these observations. From a Lean
      > viewpoint, I think
      > that number 1 is more like the definition one
      > "should" use, but it
      > seems reasonable -- even if it isn't -- that a
      > development manager
      > would like to know "how productive" his people are.
      >
      > I'd like to know a good and convincing answer to
      > that kind of
      > question.
      >

      You could use number of code-checkins/per week. If
      it's the team's job to change the codebase to add
      features, then code-checkins is a fairly direct
      measure of the team's productivity. Obviously, all
      code-checkins are not equal in value, so you probably
      want some way to account for the variation (apart from
      the law of large numbers), but let's keep things
      simple.

      If you track check-ins and story points, then I think
      you will be able to notice these trends:

      If the team has...

      1) high code-checkins per week and high story
      points/week:

      Most likely, the team is in a productive phase.

      2) low code-checkins per week and low story
      points/week

      Most likely, the team is in an unproductive phase.

      3) high code-checkins per story completed

      Needs more analysis. Could be:

      a) The stories have too much scope creep.
      b) The team may be paying down some tech debt.
      c) The team may be evolving toward more
      frequent but smaller code changes, which isn't
      necessarily a bad thing, but it will skew the analysis
      for a while.
      d) The team may be underestimating how long
      stories really take.

      4) high number of story points per code check-ins

      Needs more analysis. Could be:

      a) The team may be gaming estimate numbers to
      look productive.
      b) The team may be starting to get some payback
      on earlier refactorings, so stories have become easier
      to implement.
      c) The code check-in process may be broken
      somehow.
      d) The team may be cutting too much
      functionality out of the stories, cutting back on
      tests, or neglecting refactorings.

      Although you probably reach a point of diminishing
      returns with metrics, I'd suspect that 2 to 4 metrics
      would tend to work better than 1, since it's easy to
      game a single metric, but harder to game multiple metrics.


      ____________________________________________________________________________________
      Looking for last minute shopping deals?
      Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
    • 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.