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

Re: [XP] "Heartbeat" Check-In Metric?

Expand Messages
  • Adam Sroka
    On Sun, Jun 20, 2010 at 4:52 PM, Jeff Anderson ... Not necessarily. That whole idea of small changes that was discussed earlier in the thread can come into
    Message 1 of 35 , Jun 20, 2010
    • 0 Attachment
      On Sun, Jun 20, 2010 at 4:52 PM, Jeff Anderson
      <Thomasjeffreyandersontwin@...> wrote:
      >
      >
      >
      > A client of mine that is running a shared .Net platform as a service
      > is thinking about configuring TSS to measure frequency of checkins, we
      > are not making it part of CI but we want to create a "soft" dashboard
      > that provides some holistic indicators of health. Metrics include:
      >
      > -frequency of check ins (higher better)

      Not necessarily. That whole idea of "small changes" that was discussed
      earlier in the thread can come into play. If there are multiple
      check-ins from the same source within a few minutes of each other it
      can be someone "fixing" what they just did. Many CI servers support a
      bit of a grace period -- a few minutes timeout before the build will
      run after the last check-in. Some will exploit this to make small
      changes and never get called on it because the CI server never
      complained.

      Theoretically you can adjust your formula to correct for this behavior
      in addition to trying to educate folks not to do it. However, if you
      just look at the normalized frequency of check-ins that frequency will
      be artificially high where this behavior is present.

      > -ratio of work items opened vs number of devs on team (lower is
      > better, ie keep wip as low as possible)

      Again, I think it is a bad idea to try to track this from the tool.
      Use the board. Make sure the Scrummaster, Coach, Customer, etc. knows
      what everyone is doing.

      > -number of unique workers per work item (higher means more collaboration)

      What happens when I discover some code that does something similar to
      what I am doing and I refactor to eliminate that duplication? Does it
      now appear that I (and my pair) worked on that story? How do you
      anticipate and correct for this good practice?

      > -lead time per work unit (again lower is better)

      Also easier to identify on the board than in source control. Talk to your team!
    • Adam Sroka
      On Sun, Jun 20, 2010 at 4:52 PM, Jeff Anderson ... Not necessarily. That whole idea of small changes that was discussed earlier in the thread can come into
      Message 35 of 35 , Jun 20, 2010
      • 0 Attachment
        On Sun, Jun 20, 2010 at 4:52 PM, Jeff Anderson
        <Thomasjeffreyandersontwin@...> wrote:
        >
        >
        >
        > A client of mine that is running a shared .Net platform as a service
        > is thinking about configuring TSS to measure frequency of checkins, we
        > are not making it part of CI but we want to create a "soft" dashboard
        > that provides some holistic indicators of health. Metrics include:
        >
        > -frequency of check ins (higher better)

        Not necessarily. That whole idea of "small changes" that was discussed
        earlier in the thread can come into play. If there are multiple
        check-ins from the same source within a few minutes of each other it
        can be someone "fixing" what they just did. Many CI servers support a
        bit of a grace period -- a few minutes timeout before the build will
        run after the last check-in. Some will exploit this to make small
        changes and never get called on it because the CI server never
        complained.

        Theoretically you can adjust your formula to correct for this behavior
        in addition to trying to educate folks not to do it. However, if you
        just look at the normalized frequency of check-ins that frequency will
        be artificially high where this behavior is present.

        > -ratio of work items opened vs number of devs on team (lower is
        > better, ie keep wip as low as possible)

        Again, I think it is a bad idea to try to track this from the tool.
        Use the board. Make sure the Scrummaster, Coach, Customer, etc. knows
        what everyone is doing.

        > -number of unique workers per work item (higher means more collaboration)

        What happens when I discover some code that does something similar to
        what I am doing and I refactor to eliminate that duplication? Does it
        now appear that I (and my pair) worked on that story? How do you
        anticipate and correct for this good practice?

        > -lead time per work unit (again lower is better)

        Also easier to identify on the board than in source control. Talk to your team!
      Your message has been successfully submitted and would be delivered to recipients shortly.