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

Algorithm for Sprint Burn Down Extrapolation

Expand Messages
  • Steven Line
    Hi - We just started using Scrum a couple of weeks ago. To calculate our projected burn down we re using a 7 day linear regression algorithm. The resultant
    Message 1 of 11 , Dec 29, 2005
      Hi -

      We just started using Scrum a couple of weeks ago. To calculate our
      projected burn down we're using a 7 day linear regression algorithm.
      The resultant projected burn down line is trying to replicate the line
      of the past 7 days instead of merely project where it's currently
      headed (imagine an actual burn down that curves). If there's an
      upswing then a downswing in our actual burn down, the extrapolated burn
      down will actually jog upwards then downwards, which while
      mathematically correct for a regression, isn't communicating that the
      team is actually burning down, not backing up.

      What formula or algorithm do you use out there in scrum land?

      One suggestion we had here is to average the burn down over the last 4
      days and merely project that from the last actual burn down point.
      That's very simple and makes sense.

      Also, how many days of activity do you use to calculate your burn down
      extrapolation? We were using 7 days, but are now moving to 4.

      Thank You,
      Steve
    • Mark Striebeck
      So far, I stayed away from any extrapolation. I draw the ideal burndown line and then the actual burndown rate. The trend is usually clear. It doesn t give us
      Message 2 of 11 , Dec 29, 2005
        So far, I stayed away from any extrapolation. I draw the ideal burndown line and then the actual burndown rate. The trend is usually clear. It doesn't give us an exact measure (aka we will be 1.5 days late) but it's enough to make the team aware if corrections are needed.

             MarkS

        On 12/29/05, Steven Line <sline@...> wrote:

        Hi -

        We just started using Scrum a couple of weeks ago.  To calculate our
        projected burn down we're using a 7 day linear regression algorithm. 
        The resultant projected burn down line is trying to replicate the line
        of the past 7 days instead of merely project where it's currently
        headed  (imagine an actual burn down that curves).  If there's an
        upswing then a downswing in our actual burn down, the extrapolated burn
        down will actually jog upwards then downwards, which while
        mathematically correct for a regression, isn't communicating that the
        team is actually burning down, not backing up.

        What formula or algorithm do you use out there in scrum land?

        One suggestion we had here is to average the burn down over the last 4
        days and merely project that from the last actual burn down point. 
        That's very simple and makes sense.

        Also, how many days of activity do you use to calculate your burn down
        extrapolation?  We were using 7 days, but are now moving to 4.

        Thank You,
        Steve


        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




        YAHOO! GROUPS LINKS




      • Ron Jeffries
        ... I look at the line of actual data and extend it using a combination of what looks like a line and what my gut tells me. Either one of those, IMO, works
        Message 3 of 11 , Dec 29, 2005
          On Thursday, December 29, 2005, at 1:01:21 PM, Steven Line wrote:

          > We just started using Scrum a couple of weeks ago. To calculate our
          > projected burn down we're using a 7 day linear regression algorithm.
          > The resultant projected burn down line is trying to replicate the line
          > of the past 7 days instead of merely project where it's currently
          > headed (imagine an actual burn down that curves). If there's an
          > upswing then a downswing in our actual burn down, the extrapolated burn
          > down will actually jog upwards then downwards, which while
          > mathematically correct for a regression, isn't communicating that the
          > team is actually burning down, not backing up.

          > What formula or algorithm do you use out there in scrum land?

          > One suggestion we had here is to average the burn down over the last 4
          > days and merely project that from the last actual burn down point.
          > That's very simple and makes sense.

          > Also, how many days of activity do you use to calculate your burn down
          > extrapolation? We were using 7 days, but are now moving to 4.

          I look at the line of actual data and extend it using a combination
          of what looks like a line and what my gut tells me. Either one of
          those, IMO, works better than a formula.

          But I'm known crazy.

          Ron Jeffries
          www.XProgramming.com
          The work teaches us. -- Richard Gabriel
        • Keith Kinneberg
          ... In my experience drawing the best straight line with a straight edge gives the same result as linear least squares regression - verified by calculation a
          Message 4 of 11 , Dec 29, 2005
            >What formula or algorithm do you use out there in scrum land?
            >
            >One suggestion we had here is to average the burn down over the last 4
            >days and merely project that from the last actual burn down point.
            >That's very simple and makes sense.
            >
            >
            In my experience drawing the best straight line with a straight edge
            gives the same result
            as linear least squares regression - verified by calculation a couple of
            times. There are
            statements to this effect scattered in the scientific literature - where
            I could never say now.

            Keith
          • Steven Gordon
            Velocity is a function of sprints/iterations not days. For 2 week long sprints, I would think a window length of 1 or 2 sprints would be meaningful, whereas a
            Message 5 of 11 , Dec 29, 2005
              Velocity is a function of sprints/iterations not days. For 2 week long sprints, I would think a window length of 1 or 2 sprints would be meaningful, whereas a window length of a fraction of a sprint would often be misleading.  If you want to micromanage your velocity for some reason, you could shorten your sprints.
               
              Steven Gordon

               
              On 12/29/05, Steven Line <sline@...> wrote:

              Hi -

              We just started using Scrum a couple of weeks ago.  To calculate our
              projected burn down we're using a 7 day linear regression algorithm.
              The resultant projected burn down line is trying to replicate the line
              of the past 7 days instead of merely project where it's currently
              headed  (imagine an actual burn down that curves).  If there's an
              upswing then a downswing in our actual burn down, the extrapolated burn
              down will actually jog upwards then downwards, which while
              mathematically correct for a regression, isn't communicating that the
              team is actually burning down, not backing up.

              What formula or algorithm do you use out there in scrum land?

              One suggestion we had here is to average the burn down over the last 4
              days and merely project that from the last actual burn down point.
              That's very simple and makes sense.

              Also, how many days of activity do you use to calculate your burn down
              extrapolation?  We were using 7 days, but are now moving to 4.

              Thank You,
              Steve
            • Nick Xidis
              You re probably better off doing your tracking and projections at a interation level. I start by projecting the velocity (actual work completed) of the last
              Message 6 of 11 , Dec 30, 2005
                You're probably better off doing your tracking and projections at a interation level. I start by projecting the velocity (actual work completed) of the last iteration forward. This gives me a pretty good read on what we're actually achieveing. If there are unusal circumstances that cause me to question the results (team member was sick and should be back next time) I'll draw a second line (adjustment to velocity) before I present the results outside the team. The idea is the provide both a pure mathmatical estiamte and a experience and judgement based estimate, the truth generally lies somewhere in the neighborhood of the two.

                Based on Ron's assessment, I guess I'm 1/2 crazy.

                NX

                On 12/29/05, Steven Gordon <sgordonphd@...> wrote:
                Velocity is a function of sprints/iterations not days. For 2 week long sprints, I would think a window length of 1 or 2 sprints would be meaningful, whereas a window length of a fraction of a sprint would often be misleading.  If you want to micromanage your velocity for some reason, you could shorten your sprints.
                 
                Steven Gordon

                 
                On 12/29/05, Steven Line < sline@...> wrote:

                Hi -

                We just started using Scrum a couple of weeks ago.  To calculate our
                projected burn down we're using a 7 day linear regression algorithm.
                The resultant projected burn down line is trying to replicate the line
                of the past 7 days instead of merely project where it's currently
                headed  (imagine an actual burn down that curves).  If there's an
                upswing then a downswing in our actual burn down, the extrapolated burn
                down will actually jog upwards then downwards, which while
                mathematically correct for a regression, isn't communicating that the
                team is actually burning down, not backing up.

                What formula or algorithm do you use out there in scrum land?

                One suggestion we had here is to average the burn down over the last 4
                days and merely project that from the last actual burn down point.
                That's very simple and makes sense.

                Also, how many days of activity do you use to calculate your burn down
                extrapolation?  We were using 7 days, but are now moving to 4.

                Thank You,
                Steve


                To Post a message, send it to:   scrumdevelopment@...
                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                YAHOO! GROUPS LINKS






                --
                  Nick Xidis
                  nxidis@...

                  We are here to make another world. (Deming)
              • David H.
                ... Personally I do not think there is any formula that could safely predict a half ways reasonable regression with the amount of data you are feeding it. What
                Message 7 of 11 , Dec 30, 2005
                  Steven Line wrote:
                  > Hi -
                  >
                  > We just started using Scrum a couple of weeks ago. To calculate our
                  > projected burn down we're using a 7 day linear regression algorithm.
                  > The resultant projected burn down line is trying to replicate the line
                  > of the past 7 days instead of merely project where it's currently
                  > headed (imagine an actual burn down that curves). If there's an
                  > upswing then a downswing in our actual burn down, the extrapolated burn
                  > down will actually jog upwards then downwards, which while
                  > mathematically correct for a regression, isn't communicating that the
                  > team is actually burning down, not backing up.
                  >
                  > What formula or algorithm do you use out there in scrum land?
                  >
                  Personally I do not think there is any formula that could safely predict a
                  half ways reasonable regression with the amount of data you are feeding it.
                  What confidence intervals do you get with the regressions you are using now?

                  just as everybody else I draw the ideal burn down and then all that comes
                  along shows pretty easily. interpreting a burn down chart just needs
                  experience. Over time you learn pretty quickly what cause might be behind a
                  particular form of a burn down chart.

                  However if you wish to experiment, go and install R (www.r-project.net) with
                  that you can pretty easily perform simple linear regression models, just as
                  multiple regression models, such as One-sided test, Two-sided test and F-test.

                  -d
                • Jason Almeter
                  ... I like using several projections. We are not running full scrum, so I usually only have data on a weekly basis. I have projected the burn down with one
                  Message 8 of 11 , Jan 2, 2006
                    Ron Jeffries <ronjeffries@...> writes:

                    > On Thursday, December 29, 2005, at 1:01:21 PM, Steven Line wrote:
                    >
                    >> One suggestion we had here is to average the burn down over the last 4
                    >> days and merely project that from the last actual burn down point.
                    >> That's very simple and makes sense.
                    >
                    >> Also, how many days of activity do you use to calculate your burn down
                    >> extrapolation? We were using 7 days, but are now moving to 4.
                    >
                    > I look at the line of actual data and extend it using a combination
                    > of what looks like a line and what my gut tells me. Either one of
                    > those, IMO, works better than a formula.

                    I like using several projections. We are not running full scrum, so I
                    usually only have data on a weekly basis. I have projected the burn
                    down with one week, two week, one month, and one quarter of data. All
                    of these on a plot together help call out changes in the burn rate.
                    One of my recent victories was getting a team to see that we were in
                    trouble and then watching them brutally cut scope until we were back
                    on track.

                    -jla

                    --

                    jalmeter under 99 at yahoo
                  • Ron Jeffries
                    ... Well, in a quarter, you should be done. ;- I d be interested to see one of your charts to get a sense of what they look like and how they call out changes
                    Message 9 of 11 , Jan 2, 2006
                      On Monday, January 2, 2006, at 8:52:01 AM, Jason Almeter wrote:

                      > I like using several projections. We are not running full scrum, so I
                      > usually only have data on a weekly basis. I have projected the burn
                      > down with one week, two week, one month, and one quarter of data. All
                      > of these on a plot together help call out changes in the burn rate.
                      > One of my recent victories was getting a team to see that we were in
                      > trouble and then watching them brutally cut scope until we were back
                      > on track.

                      Well, in a quarter, you should be done. ;->

                      I'd be interested to see one of your charts to get a sense of what
                      they look like and how they call out changes in the burn rate.

                      I'd also be interested in understanding why there are substantial
                      changes in the burn rate ...

                      Ron Jeffries
                      www.XProgramming.com
                      Perhaps this Silver Bullet will tell you who I am ...
                    • Dave Bly
                      Here s one simple approach: If you are charting your burndown on an Excel chart, right-click on the data plot line and select Add Trendline to show a simple
                      Message 10 of 11 , Jan 3, 2006

                        Here’s one simple approach:  If you are charting your burndown on an Excel chart, right-click on the data plot line and select “Add Trendline” to show a simple least-squares fit. It will extrapolate that fit line to the end of the chart, i.e. the number of plat point on the X axis.  -- Dave

                         


                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Mark Striebeck
                        Sent: Thursday, December 29, 2005 10:12 AM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: [Norton AntiSpam] Re: [scrumdevelopment] Algorithm for Sprint Burn Down Extrapolation

                         

                        So far, I stayed away from any extrapolation. I draw the ideal burndown line and then the actual burndown rate. The trend is usually clear. It doesn't give us an exact measure (aka we will be 1.5 days late) but it's enough to make the team aware if corrections are needed.

                             MarkS

                        On 12/29/05, Steven Line <sline@...> wrote:


                        Hi -

                        We just started using Scrum a couple of weeks ago.  To calculate our
                        projected burn down we're using a 7 day linear regression algorithm. 
                        The resultant projected burn down line is trying to replicate the line
                        of the past 7 days instead of merely project where it's currently
                        headed  (imagine an actual burn down that curves).  If there's an
                        upswing then a downswing in our actual burn down, the extrapolated burn
                        down will actually jog upwards then downwards, which while
                        mathematically correct for a regression, isn't communicating that the
                        team is actually burning down, not backing up.

                        What formula or algorithm do you use out there in scrum land?

                        One suggestion we had here is to average the burn down over the last 4
                        days and merely project that from the last actual burn down point. 
                        That's very simple and makes sense.

                        Also, how many days of activity do you use to calculate your burn down
                        extrapolation?  We were using 7 days, but are now moving to 4.

                        Thank You,
                        Steve


                        To Post a message, send it to:   scrumdevelopment@...
                        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                        YAHOO! GROUPS LINKS

                         

                         




                      • Hubert Smits
                        Just like Ron I d be interested to learn more about your approach. I don t understand how looking at more then one week gives you information about successful
                        Message 11 of 11 , Jan 3, 2006
                          Just like Ron I'd be interested to learn more about your approach. I
                          don't understand how looking at more then one week gives you
                          information about successful completion of a sprint/iteration. But
                          then, where Ron is stubborn, I am Dutch so that may explain it :-)

                          --Hubert



                          On 1/2/06, Ron Jeffries <ronjeffries@...> wrote:
                          > On Monday, January 2, 2006, at 8:52:01 AM, Jason Almeter wrote:
                          >
                          > > I like using several projections. We are not running full scrum, so I
                          > > usually only have data on a weekly basis. I have projected the burn
                          > > down with one week, two week, one month, and one quarter of data. All
                          > > of these on a plot together help call out changes in the burn rate.
                          > > One of my recent victories was getting a team to see that we were in
                          > > trouble and then watching them brutally cut scope until we were back
                          > > on track.
                          >
                          > Well, in a quarter, you should be done. ;->
                          >
                          > I'd be interested to see one of your charts to get a sense of what
                          > they look like and how they call out changes in the burn rate.
                          >
                          > I'd also be interested in understanding why there are substantial
                          > changes in the burn rate ...
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > Perhaps this Silver Bullet will tell you who I am ...
                          >
                          >
                          > To Post a message, send it to: scrumdevelopment@...
                          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.