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

Re: [scrumdevelopment] Re: calculate velocity

Expand Messages
  • Markus Gaertner
    I probably only speak from my own experiences there, but I have seen most teams being perfectly comfortable with seeing the progress they make on their
    Message 1 of 10 , Feb 13, 2013
    • 0 Attachment
      I probably only speak from my own experiences there, but I have seen
      most teams being perfectly comfortable with seeing the progress they
      make on their taskboard. When there are four days in the sprint left,
      and just one out of five stories is finished, they exactly know they
      have bad news, and need to speak to the product owner about it. On the
      other hand, if four days before sprint review four out of five stories
      are done, and the PO had a look on them, and the fifth story is
      half-way through, they know, they are likely to finish that last story
      as well.

      Usually the visual impression of the taskboard gives clues to your
      progress. And you update that one anyways. The teams I worked with
      were pretty comfortable with that.

      Best
      Markus

      On Tue, Feb 12, 2013 at 5:42 PM, czahn777 <czahn@...> wrote:
      > Hi,
      > first of all thank you for your responses!
      >
      > The reason why i calculate the velocity on a day-by-day basis is,
      > that i want to calculate a forecast for a sprint. Just as an additional information to the normal burndown chart!
      > I just want to know, if we will finish all stories in the calculated sprint time.
      >
      > So i took the average burndown hours(!) per day and use it as a forecast value. This value now shows to me, when we go on with this 'velocity', we will finish all the stories in this sprint until day X, Y or Z.
      > And no, i don't want to vary the length, i just want to know if we are in time.
      >
      > For your background. We have just started with this project and there is no last sprint yet. And there are no references for this sprint and its velocity.
      >
      > regards,
      > Christof
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, Markus Gaertner wrote:
      >>
      >> Hi Christof,
      >>
      >> Scrum doesn't say anything about velocity or burn-ups. Usually during
      >> courses I ask participants for good reasons to come up with stuff like
      >> these. The only answer yet has boiled down to rendezvous planning with some
      >> other group or team.
      >>
      >> Now, I am curious, what daily rendezvous do you face that makes you
      >> evaluate the velocity on a day-by-day basis?
      >>
      >> Best
      >> Markus
      >>
      >> On Mon, Feb 11, 2013 at 5:38 PM, Christof Zahn wrote:
      >>
      >> >
      >> >
      >> > Hi group,
      >> >
      >> > how do you calculate the burndown rate / velocity for a sprint?
      >> > Here's my example / My understanding:
      >> >
      >> > Start: 42 hours left
      >> > End of Day 1: 36 hours left
      >> > End of Day 2; 28 hours left
      >> > End of Day 3: 18 hours left
      >> >
      >> > Velocity for
      >> > Day 1 is 6 hours (42 minus 36)
      >> > Day 2 is 8 hours
      >> > Day 3 is 10 hours
      >> > Avg. : 8 hours
      >> >
      >> > So the velocity is nothing more than the "burned down" points or hours per
      >> > day.
      >> > Am I correct?
      >> >
      >> > And with that information, how will you do the forecast?
      >> > Take the average velocity or the one from the actual day?
      >> > Maybe it even depends on the sprint length?! Because the velocity at the
      >> > beginning of the sprint is much slower.
      >> > So an average value will be not so representative for a good forecast.
      >> >
      >> >
      >> > regards,
      >> > christof
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >>
      >>
      >>
      >>
      >> --
      >> Dipl.-Inform. Markus Gärtner
      >> Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
      >> Development
      >> http://www.shino.de/blog
      >> http://www.mgaertne.de
      >> http://www.it-agile.de
      >> Twitter: @mgaertne
      >>
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      >
      >
      >



      --
      Dipl.-Inform. Markus Gärtner
      Author of ATDD by Example - A Practical Guide to Acceptance
      Test-Driven Development
      http://www.shino.de/blog
      http://www.mgaertne.de
      http://www.it-agile.de
      Twitter: @mgaertne
    • extremeprogrammer
      I advise you not do do this for two reasons: 1. Many teams have a burndown signature that is visible after several sprints. This arises from the teams
      Message 2 of 10 , Feb 14, 2013
      • 0 Attachment
        I advise you not do do this for two reasons:

        1. Many teams have a "burndown signature" that is visible after several sprints. This arises from the teams preferences, maybe for doing a few small stories first, then tackling hard ones, leaving some smaller ones at the end, or maybe they tackle the hard ones first, etc. The belief that the burndown should follow some sort of "ideal" line is clinging to the old world.

        2. http://www.casualmiracles.com/2011/05/16/burndown-prediction-confidence-and-risk/

        Regards,

        Lance

        --- In scrumdevelopment@yahoogroups.com, "czahn777" wrote:
        >
        > Hi,
        > first of all thank you for your responses!
        >
        > The reason why i calculate the velocity on a day-by-day basis is,
        > that i want to calculate a forecast for a sprint. Just as an additional information to the normal burndown chart!
        > I just want to know, if we will finish all stories in the calculated sprint time.
        >
        > So i took the average burndown hours(!) per day and use it as a forecast value. This value now shows to me, when we go on with this 'velocity', we will finish all the stories in this sprint until day X, Y or Z.
        > And no, i don't want to vary the length, i just want to know if we are in time.
        >
        > For your background. We have just started with this project and there is no last sprint yet. And there are no references for this sprint and its velocity.
        >
        > regards,
        > Christof
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, Markus Gaertner wrote:
        > >
        > > Hi Christof,
        > >
        > > Scrum doesn't say anything about velocity or burn-ups. Usually during
        > > courses I ask participants for good reasons to come up with stuff like
        > > these. The only answer yet has boiled down to rendezvous planning with some
        > > other group or team.
        > >
        > > Now, I am curious, what daily rendezvous do you face that makes you
        > > evaluate the velocity on a day-by-day basis?
        > >
        > > Best
        > > Markus
        > >
        > > On Mon, Feb 11, 2013 at 5:38 PM, Christof Zahn wrote:
        > >
        > > >
        > > >
        > > > Hi group,
        > > >
        > > > how do you calculate the burndown rate / velocity for a sprint?
        > > > Here's my example / My understanding:
        > > >
        > > > Start: 42 hours left
        > > > End of Day 1: 36 hours left
        > > > End of Day 2; 28 hours left
        > > > End of Day 3: 18 hours left
        > > >
        > > > Velocity for
        > > > Day 1 is 6 hours (42 minus 36)
        > > > Day 2 is 8 hours
        > > > Day 3 is 10 hours
        > > > Avg. : 8 hours
        > > >
        > > > So the velocity is nothing more than the "burned down" points or hours per
        > > > day.
        > > > Am I correct?
        > > >
        > > > And with that information, how will you do the forecast?
        > > > Take the average velocity or the one from the actual day?
        > > > Maybe it even depends on the sprint length?! Because the velocity at the
        > > > beginning of the sprint is much slower.
        > > > So an average value will be not so representative for a good forecast.
        > > >
        > > >
        > > > regards,
        > > > christof
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > >
        > >
        > >
        > >
        > > --
        > > Dipl.-Inform. Markus Gärtner
        > > Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
        > > Development
        > > http://www.shino.de/blog
        > > http://www.mgaertne.de
        > > http://www.it-agile.de
        > > Twitter: @mgaertne
        > >
        >
      • wwake2
        ... +1 for taskboards over sprint burndowns When I m halfway through a sprint, I d like to see say 40%+ of stories in the done column. That gives me a better
        Message 3 of 10 , Feb 14, 2013
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, Markus Gaertner wrote:
          >
          > I probably only speak from my own experiences there, but I have seen
          > most teams being perfectly comfortable with seeing the progress they
          > make on their taskboard.

          +1 for taskboards over sprint burndowns

          When I'm halfway through a sprint, I'd like to see say 40%+ of stories in the "done" column. That gives me a better indication of progress than seeing that we've burned down half the work we expect to do.

          I've found the taskboard leads the team to focus more on stories ("what *we're* trying to do") and less on tasks ("what *I'm* trying to do").

          --
          Bill Wake @wwake http://xp123.com
          Industrial Logic, Inc. - Coaching, Training, Assessment, eLearning - http://industriallogic.com
        Your message has been successfully submitted and would be delivered to recipients shortly.