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

Re: Do you count weekends in your burn down chart?

Expand Messages
  • Victor Szalvay
    Hi Dan, You re right! I don t like any metrics being performed at the sprint task level, especially one like this that tries to extrapolate whether a team
    Message 1 of 51 , Jun 1, 2006
      Hi Dan,

      You're right! I don't like any metrics being performed at the sprint
      task level, especially one like this that tries to extrapolate whether
      a team will be done with their sprint work.

      One of the ways Scrum/Agile differentiates from traditional project
      management is a focus on what I'll call "macro" metrics instead of
      "micro" metrics. Focusing metrics at the micro (or task) level causes
      a variety of problems in Scrum teams. There is the principle that
      "you get what you measure", and if your metric is sub-optimum then
      teams will start performing to this sub-optimum metric. So the
      question is "in Agile/Scrum, what would be the best metric"? Most
      Agilists believe that metric to be the rate at which the product is
      actually produced (velocity). That's why in Scrum the team should be
      measured by whether or not they meet sprint goals (think product
      backlog item level or higher) since the sprint goals should always
      represent tangible progress on the product. I call these measurements
      macro metrics.

      Velocity is not measured at the task level, it is a "once a sprint"
      data point that comes from the sprint review. If the product owner
      believes the committed product backlog items are done, then the team
      gets "credit" for those items in terms of velocity.

      The burndown chart and trend I believe Ron Jeffries is referring to in
      his post is actually a "release burndown chart" (Ron, correct me if
      I'm wrong here!). This tracks the rate at which actual work
      increments are being done by the team, new work is being added to the
      backlog, etc. I do like this metric because it encourages behavior
      that is optimized for the real goal product development.

      Check out Mike Cohn's new book on Agile Estimating and Planning for
      more on this.

      Hope this helps,
      -- Victor Szalvay
      Danube Technologies, Inc.
      http://danube.com
      --- In scrumdevelopment@yahoogroups.com, "Dan Pierce" <dan.pierce@...>
      wrote:
      >
      > Victor,
      >
      > It seems to me that all of your comments apply to all measurements
      > and metrics everywhere in every field. The many gauges on a race
      > car (or the space shuttle for that matter) can hide vital truths
      > about what is "really" going on. The Dow Jones' many indexes are
      > constantly debated for their "true" meanings. Doctors caution other
      > doctors against "treating the numbers", etc.
      >
      > All metrics are distortions and abstractions but that does not mean
      > they are not useful. It just means we have to be vigilent about
      > what they can show and what they can hide.
      >
      > Dan Pierce
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, "Victor Szalvay"
      > <victor@> wrote:
      > >
      > > Actually I've never had much use for a sprint burndown trendline at
      > > all. They can be dubious and misleading themselves because only
      > the
      > > team has any real sense for how things are going based the
      > culminating
      > > facts of the sprint. The sprint burndown is there just as a
      > reminder
      > > of that history, but it is not conclusive by itself to anyone
      > outside
      > > the team.
      > >
      > > To illustrate this with an example, consider a team that is stuck
      > by a
      > > bug or impediment and the sprint burndown curve is "hung up". If
      > you
      > > extrapolate a trend the team clearly won't make the sprint.
      > However,
      > > the team knows that they are on the verge of a breakthrough and
      > once
      > > that happens they will be able to finish in time. In this case,
      > what
      > > does the trendline do for you? At worst, it may cause tension
      > between
      > > the SM/PO and the team because no one but the team members can
      > > understand why the team thinks they will still make it on time.
      > >
      > > The opposite scenario also supports this. Consider a team whose
      > graph
      > > looks like they will easily finish but they know they've been
      > putting
      > > off a high risk section of the sprint work that may spell disaster
      > for
      > > the sprint goals. In this case, a trendline lulls everyone into a
      > > feeling of safety; however, the team knows this is not reality.
      > >
      > > I guess what I'm saying is that the sprint burndown chart is
      > worthless
      > > without being part of the team and knowing exactly why it trends
      > the
      > > way it does (or went up before it went down and then went back up
      > > again). The sprint burndown is a tool for the team to remind
      > itself
      > > where it stands as of today and how it got there, but trending
      > doesn't
      > > seem to buy you any meaningful predictability. It is then up to
      > the
      > > team itself as to how honest and forthright it wants to be in the
      > face
      > > of trouble.
      > >
      > > I hope this makes sense and helps convey a little of my experience
      > > with the sprint burndown.
      > >
      > > -- Victor Szalvay
      > > Danube Technologies, Inc.
      > > http://danube.com
      > >
    • Nicholas Cancelliere
      I do not unless your team is planning on working weekends all the time, and lets hope not! :-) -Nick ... From: Ilja Preuss To:
      Message 51 of 51 , Jun 24, 2006
        I do not unless your team is planning on working weekends all the time, and lets hope not!  :-)
         
        -Nick
         
         
        ----- Original Message -----
        Sent: Friday, June 02, 2006 1:13 AM
        Subject: RE: [scrumdevelopment] Re: Do you count weekends in your burn down chart?

        > Ron,
        > I hope your question is rhetorical because clearly I can't
        > answer something in a yahoo group posting that you've not
        > been able to achieve in 2 years of work.

        I didn't see anything in Ron's post suggesting that he wasn't able to help
        those teams.

        > I agree this is a problem and I see it often myself.  I don't
        > think dumping additional metrics on top of the sprint
        > burndown is going to solve this problem though.

        Well, yes - just dumping it on the sprint burndown is probably not the most
        effective way to use a trendline; it's certainly nothing I would suggest to
        do.


        Take care, Ilja

        --
        "Information Radiation in Practice -
        Communication Tools for Colocated Teams"

        Tutorial at the XP2006 conference, Oulu
        www.xp2006.org
        17.06.2006

      Your message has been successfully submitted and would be delivered to recipients shortly.