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

What to put in the sprint backlog, and how to use burndown chart ideal lines

Expand Messages
  • thomas strandenaes
    Some scrum coaches suggest that team member activities in a sprint that are not related to product backlog items (like vacations) should be put into the sprint
    Message 1 of 9 , Oct 29, 2008
    • 0 Attachment
      Some scrum coaches suggest that team member activities in a sprint that are not related to product backlog items (like vacations) should be put into the sprint backlog as items, and burned down as the sprint progresses. In this way the team will seem to stay closer to the ideal line in the burndown chart even during team member vacations, and team member absences are visualized to the team. However the team will seem to be burning down work even when team members are on vacation when using this suggestion, and the sprint backlog is 'polluted' with non product backlog related work.

      What seems to be a more common suggestion is to subtract vacations and similar from the team capacity during sprint planning and keep these activities away from the sprint backlog entirely. If using a straight ideal line in the burndown chart (not corrected for varying team capacity), the team may however think they are on track in the sprint until the team member vacation starts, and then never recover completely during the sprint/not be able to meet their commitment, as the ideal line assumed constant capacity throughout the sprint.

      What is the group optinion on using burndown chart ideal lines, related to the two practices described above? and how do you handle abscence like vacations and other activities that not related to the sprint, in relation to the sprint backlog?

      I prefer to keep vacations and similar out of the sprint backlog, as I want the burndown chart to show product item related burndown only. I think using ideal lines in the burndown charts can confuse teams into believing they need to stay close to this line at all times - which obviously has no value in it self since work and sprint backlog items naturally will emerge and change in the sprint in somewhat unpredictable ways.

      Best regards,

      --
      Thomas Strandenaes


      _________________________________________________________
      Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
      notisblokk. http://no.mail.yahoo.com
    • Tobias Mayer
      Thomas, I believe your instinct is correct.  This is what I recommend to teams: 1. Product Backlog had ONLY user-value stories in it.  Nothing else. 2. Only
      Message 2 of 9 , Oct 29, 2008
      • 0 Attachment
        Thomas, I believe your instinct is correct. 

        This is what I recommend to teams:

        1. Product Backlog had ONLY user-value stories in it.  Nothing else.

        2. Only stories are tracked in a sprint.  Burn down should be on stories (and/or story points) as these are true units of business value.  Tasks and hours are not.

        3. Knowledge about vacations, infrastructure work, etc, should be made visible in the planning meeting and accounted for when the team commits.

        Note: #2 is at odds with many Scrum practitioners.  It works for the teams I have coached though.  I have yet to hear a really compelling reason for tracking tasks or hours, i.e. a reason that has nothing to do with compliance.

        Tobias




        That's all.  Keep it as simple as you can.

        --- On Wed, 10/29/08, thomas strandenaes <thostr@...> wrote:
        From: thomas strandenaes <thostr@...>
        Subject: [scrumdevelopment] What to put in the sprint backlog, and how to use burndown chart ideal lines
        To: scrumdevelopment@yahoogroups.com
        Date: Wednesday, October 29, 2008, 2:48 PM

        Some scrum coaches suggest that team member activities in a sprint that are not related to product backlog items (like vacations) should be put into the sprint backlog as items, and burned down as the sprint progresses. In this way the team will seem to stay closer to the ideal line in the burndown chart even during team member vacations, and team member absences are visualized to the team. However the team will seem to be burning down work even when team members are on vacation when using this suggestion, and the sprint backlog is 'polluted' with non product backlog related work.

        What seems to be a more common suggestion is to subtract vacations and similar from the team capacity during sprint planning and keep these activities away from the sprint backlog entirely. If using a straight ideal line in the burndown chart (not corrected for varying team capacity), the team may however think they are on track in the sprint until the team member vacation starts, and then never recover completely during the sprint/not be able to meet their commitment, as the ideal line assumed constant capacity throughout the sprint.

        What is the group optinion on using burndown chart ideal lines, related to the two practices described above? and how do you handle abscence like vacations and other activities that not related to the sprint, in relation to the sprint backlog?

        I prefer to keep vacations and similar out of the sprint backlog, as I want the burndown chart to show product item related burndown only. I think using ideal lines in the burndown charts can confuse teams into believing they need to stay close to this line at all times - which obviously has no value in it self since work and sprint backlog items naturally will emerge and change in the sprint in somewhat unpredictable ways.

        Best regards,

        --
        Thomas Strandenaes

        ____________ _________ _________ _________ _________ _________
        Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
        notisblokk. http://no.mail. yahoo.com

      • Michael James
        I also discourage drawing an ideal line as this exerts a subtle pressure to make our actuals appear to match our plan. --mj ... points) as these are true
        Message 3 of 9 , Oct 29, 2008
        • 0 Attachment
          I also discourage drawing an "ideal line" as this exerts a subtle pressure
          to make our actuals appear to match our plan.

          --mj

          --- In scrumdevelopment@yahoogroups.com, Tobias Mayer <tobias.mayer@...> wrote:
          >
          > Thomas, I believe your instinct is correct. 
          >
          > This is what I recommend to teams:
          >
          > 1. Product Backlog had ONLY user-value stories in it.  Nothing else.
          >
          > 2. Only stories are tracked in a sprint.  Burn down should be on stories (and/or story
          points) as these are true units of business value.  Tasks and hours are not.
          >
          > 3. Knowledge about vacations, infrastructure work, etc, should be made visible in the
          planning meeting and accounted for when the team commits.
          >
          > Note: #2 is at odds with many Scrum practitioners.  It works for the teams I have
          coached though.  I have yet to hear a really compelling reason for tracking tasks or hours,
          i.e. a reason that has nothing to do with compliance.
          >
          > Tobias
          >
          >
          >
          >
          > That's all.  Keep it as simple as you can.
          >
          > --- On Wed, 10/29/08, thomas strandenaes <thostr@...> wrote:
          > From: thomas strandenaes <thostr@...>
          > Subject: [scrumdevelopment] What to put in the sprint backlog, and how to use
          burndown chart ideal lines
          > To: scrumdevelopment@yahoogroups.com
          > Date: Wednesday, October 29, 2008, 2:48 PM
          >
          >
          >
          >
          >
          >
          >
          >
          >
          >
          >
          > Some scrum coaches suggest that team member activities in a sprint that are not
          related to product backlog items (like vacations) should be put into the sprint backlog as
          items, and burned down as the sprint progresses. In this way the team will seem to stay
          closer to the ideal line in the burndown chart even during team member vacations, and
          team member absences are visualized to the team. However the team will seem to be
          burning down work even when team members are on vacation when using this suggestion,
          and the sprint backlog is 'polluted' with non product backlog related work.
          >
          >
          >
          > What seems to be a more common suggestion is to subtract vacations and similar from
          the team capacity during sprint planning and keep these activities away from the sprint
          backlog entirely. If using a straight ideal line in the burndown chart (not corrected for
          varying team capacity), the team may however think they are on track in the sprint until
          the team member vacation starts, and then never recover completely during the sprint/not
          be able to meet their commitment, as the ideal line assumed constant capacity throughout
          the sprint.
          >
          >
          >
          > What is the group optinion on using burndown chart ideal lines, related to the two
          practices described above? and how do you handle abscence like vacations and other
          activities that not related to the sprint, in relation to the sprint backlog?
          >
          >
          >
          > I prefer to keep vacations and similar out of the sprint backlog, as I want the burndown
          chart to show product item related burndown only. I think using ideal lines in the
          burndown charts can confuse teams into believing they need to stay close to this line at all
          times - which obviously has no value in it self since work and sprint backlog items
          naturally will emerge and change in the sprint in somewhat unpredictable ways.
          >
          >
          >
          > Best regards,
          >
          >
          >
          > --
          >
          > Thomas Strandenaes
          >
          >
          >
          > ____________ _________ _________ _________ _________ _________
          >
          > Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
          >
          > notisblokk. http://no.mail yahoo.com
          >
        • Steve Berczuk
          ... But isn t the point of the ideal like to predict when you are tracking at a rate that will not get you to the end? At one point I tried doing an expected
          Message 4 of 9 , Oct 29, 2008
          • 0 Attachment
            On Wed, Oct 29, 2008 at 9:24 PM, Michael James <michael@...> wrote:
            > I also discourage drawing an "ideal line" as this exerts a subtle pressure
            > to make our actuals appear to match our plan.

            But isn't the point of the ideal like to predict when you are tracking
            at a rate that will not get you to the end?

            At one point I tried doing an "expected work remaining" calculation,
            and when that number got too far above 0 we took a harder look at the
            backlog.

            I've also used an "ideal" line that reflected the capacity of the team
            in terms of meetings, vacation, etc...

            I've used the ideal line as more of a "flag": below the line, all is
            well, above the line: lets look more closely.

            It probably does not make sense to treat it as anything more than
            that, It IS important to have some sort of visible indicator of how
            the team is doing relative to the goal.

            Steve
            --
            Steve Berczuk | steve@... | http://www.berczuk.com
            SCM Patterns: Effective Teamwork, Practical Integration
            www.scmpatterns.com
          • George Dinwiddie
            ... Doesn t this whisper to the team that it s better to err on the side of under committing than over committing? ... I d rather just eyeball it than to draw
            Message 5 of 9 , Oct 29, 2008
            • 0 Attachment
              Steve Berczuk wrote:
              > I've used the ideal line as more of a "flag": below the line, all is
              > well, above the line: lets look more closely.

              Doesn't this whisper to the team that it's better to err on the side of
              under committing than over committing?

              > It probably does not make sense to treat it as anything more than
              > that, It IS important to have some sort of visible indicator of how
              > the team is doing relative to the goal.

              I'd rather just eyeball it than to draw in the line. Having a line
              implies more precision than is warranted. It's all based on estimates,
              anyway.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • woynam
              I agree with Michael. There is no such thing as ideal. I don t recall the last time I saw a burndown that looked anything like a straight line. In fact, I ve
              Message 6 of 9 , Oct 30, 2008
              • 0 Attachment
                I agree with Michael. There is no such thing as ideal. I don't recall
                the last time I saw a burndown that looked anything like a straight line.

                In fact, I've worked with several teams that have their own unique
                fingerprint. The Sprints generally start rather flat, then dive
                sharply, and then flatten out towards the end. Many of us have seen
                this pattern often.

                A good SM can generally sense when a team is getting close to the
                danger zone without the need for a line on the graph.

                Mark

                --- In scrumdevelopment@yahoogroups.com, "Steve Berczuk"
                <steve.berczuk@...> wrote:
                >
                > On Wed, Oct 29, 2008 at 9:24 PM, Michael James <michael@...> wrote:
                > > I also discourage drawing an "ideal line" as this exerts a subtle
                pressure
                > > to make our actuals appear to match our plan.
                >
                > But isn't the point of the ideal like to predict when you are tracking
                > at a rate that will not get you to the end?
                >
                > At one point I tried doing an "expected work remaining" calculation,
                > and when that number got too far above 0 we took a harder look at the
                > backlog.
                >
                > I've also used an "ideal" line that reflected the capacity of the team
                > in terms of meetings, vacation, etc...
                >
                > I've used the ideal line as more of a "flag": below the line, all is
                > well, above the line: lets look more closely.
                >
                > It probably does not make sense to treat it as anything more than
                > that, It IS important to have some sort of visible indicator of how
                > the team is doing relative to the goal.
                >
                > Steve
                > --
                > Steve Berczuk | steve@... | http://www.berczuk.com
                > SCM Patterns: Effective Teamwork, Practical Integration
                > www.scmpatterns.com
                >
              • Mike Sutton
                Hi Thomas, really good feedback so far...here is some more along the same line of thinking. I recommend story points for estimating stories (doh!), but once
                Message 7 of 9 , Nov 2, 2008
                • 0 Attachment
                  Hi Thomas,

                  really good feedback so far...here is some more along the same line of
                  thinking.

                  I recommend story points for estimating stories (doh!), but once we
                  get to sprint planning, I find it useful for teams to determine how
                  much time they will have over the coming sprint (taking into account
                  holidays, other project commitments etc). They do it individually and
                  then derive a total team time , which is then used to guide them in
                  their commitment. (I find it useful for the Scrum Master to facilitate
                  this, he/she can use it to trawl for impediments - like non-project
                  work that distracts the team or particular members).

                  If in the course of the sprint something unexpected happens (like
                  someone gets ill), its then pretty easy to show this on a sprint burn
                  down (actually we add up the lost time to the sprint backlog - the
                  estimated hours to the burn down to show what time we have lost by
                  that unexpected event) - we can use this data at the next daily scrum
                  to determine the impact of that issue - whether we need to descope
                  etc.(of course the PO does this, but the team triggers the call!).


                  The sprint burndown (when we use it) tracks hours remaining but thats
                  about it - I strongly suggest teams don't draw trend lines or anything
                  else - I prefer the team to do the predictions of how they think they
                  will do (gut feel), it may be completely inaccurate at first, but
                  without encouraging them to do this, they will never get good at
                  instinctive predictions - which IMHO is a really good skill for teams.


                  hope this helps.
                  Mike
                  csm.csp.cspo.certified.certifiable.

                  --- In scrumdevelopment@yahoogroups.com, Tobias Mayer
                  <tobias.mayer@...> wrote:
                  >
                  > Thomas, I believe your instinct is correct. 
                  >
                  > This is what I recommend to teams:
                  >
                  > 1. Product Backlog had ONLY user-value stories in it.  Nothing else.
                  >
                  > 2. Only stories are tracked in a sprint.  Burn down should be on
                  stories (and/or story points) as these are true units of business
                  value.  Tasks and hours are not.
                  >
                  > 3. Knowledge about vacations, infrastructure work, etc, should be
                  made visible in the planning meeting and accounted for when the team
                  commits.
                  >
                  > Note: #2 is at odds with many Scrum practitioners.  It works for the
                  teams I have coached though.  I have yet to hear a really compelling
                  reason for tracking tasks or hours, i.e. a reason that has nothing to
                  do with compliance.
                  >
                  > Tobias
                  >
                  >
                  >
                  >
                  > That's all.  Keep it as simple as you can.
                  >
                  > --- On Wed, 10/29/08, thomas strandenaes <thostr@...> wrote:
                  > From: thomas strandenaes <thostr@...>
                  > Subject: [scrumdevelopment] What to put in the sprint backlog, and
                  how to use burndown chart ideal lines
                  > To: scrumdevelopment@yahoogroups.com
                  > Date: Wednesday, October 29, 2008, 2:48 PM
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  > Some scrum coaches suggest that team member activities
                  in a sprint that are not related to product backlog items (like
                  vacations) should be put into the sprint backlog as items, and burned
                  down as the sprint progresses. In this way the team will seem to stay
                  closer to the ideal line in the burndown chart even during team member
                  vacations, and team member absences are visualized to the team.
                  However the team will seem to be burning down work even when team
                  members are on vacation when using this suggestion, and the sprint
                  backlog is 'polluted' with non product backlog related work.
                  >
                  >
                  >
                  > What seems to be a more common suggestion is to subtract vacations
                  and similar from the team capacity during sprint planning and keep
                  these activities away from the sprint backlog entirely. If using a
                  straight ideal line in the burndown chart (not corrected for varying
                  team capacity), the team may however think they are on track in the
                  sprint until the team member vacation starts, and then never recover
                  completely during the sprint/not be able to meet their commitment, as
                  the ideal line assumed constant capacity throughout the sprint.
                  >
                  >
                  >
                  > What is the group optinion on using burndown chart ideal lines,
                  related to the two practices described above? and how do you handle
                  abscence like vacations and other activities that not related to the
                  sprint, in relation to the sprint backlog?
                  >
                  >
                  >
                  > I prefer to keep vacations and similar out of the sprint backlog, as
                  I want the burndown chart to show product item related burndown only.
                  I think using ideal lines in the burndown charts can confuse teams
                  into believing they need to stay close to this line at all times -
                  which obviously has no value in it self since work and sprint backlog
                  items naturally will emerge and change in the sprint in somewhat
                  unpredictable ways.
                  >
                  >
                  >
                  > Best regards,
                  >
                  >
                  >
                  > --
                  >
                  > Thomas Strandenaes
                  >
                  >
                  >
                  > ____________ _________ _________ _________ _________ _________
                  >
                  > Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
                  >
                  > notisblokk. http://no.mail yahoo.com
                  >
                • thostr
                  Hi Mike, I am also very pleased with the discussion that my request has spawned on the list, and I agree on the possible fallacy of using a trend line. However
                  Message 8 of 9 , Nov 2, 2008
                  • 0 Attachment
                    Hi Mike,
                    I am also very pleased with the discussion that my request has spawned
                    on the list, and I agree on the possible fallacy of using a trend
                    line. However there is one thing in your description that I would like
                    you to elaborate on:

                    | If in the course of the sprint something unexpected
                    | happens (like someone gets ill), its then pretty easy
                    | to show this on a sprint burn down (actually we add
                    | up the lost time to the sprint backlog - the estimated
                    | hours to the burn down to show what time we have
                    | lost by that unexpected event)

                    I understand that you 'exaggerate' the consequences of someone being
                    unexpectedly away by adding 'lost work' to the SBL, and by doing so
                    intend to make the possible consequences of somone being away more
                    visible to the team. However I find this slightly irrational as the
                    estimated amount of work left to do does not automatically increase
                    when a team member is away from the team. This practice looks like the
                    inverse practice of putting planned holidays and similar into the
                    sprint backlog. It makes the burndown chart read more dramatically,
                    but I would think that the team is better off learning how to read the
                    burndown chart based on actual estimated effort left. I guess you have
                    observations that suggest otherwise?

                    --
                    t
                  • James S. Fosdick, PMP, CSP
                    ... stories (and/or story points) as these are true units of business value.  Tasks and hours are not. ... teams I have coached though.  I have yet to hear a
                    Message 9 of 9 , Nov 3, 2008
                    • 0 Attachment
                      > 2. Only stories are tracked in a sprint.  Burn down should be on
                      stories (and/or story points) as these are true units of business
                      value.  Tasks and hours are not.
                      > Note: #2 is at odds with many Scrum practitioners.  It works for the
                      teams I have coached though.  I have yet to hear a really compelling
                      reason for tracking tasks or hours, i.e. a reason that has nothing to
                      do with compliance.

                      You take some of the force out of controversy when you acknowledge it
                      ahead of time. :P

                      As you have correctly anticipated I agree with every point save #2.
                      Before I elaborate I will offer my usual caveat that we should not be
                      too prescriptive (either in advocating for or against a particular
                      approach to the sprint burndown).

                      So why track tasks, using hours, in the sprint burndown? In my view
                      the sprint burndown is NOT primarily concerned with the accumulation
                      of business value. For that we have Product Burndown, Burn-UP, earned
                      business value etc. Rather the sprint burndown is for the team to
                      manage work remaining in the sprint. Work remaining is only loosely
                      and indirectly correlated with stories (as represented by story
                      points). In order to be useful the sprint burndown needs to have two
                      properties. Firstly it needs to be sufficiently granular that it
                      changes from day to day so we can inspect and adapt at each standup.
                      If we are using stories as the metric it may not change for several
                      days which reduces it's utility in my opinion. Secondly it needs to
                      accommodate the phenomenon of emerging work. Now it could be argued
                      that we can simply write new stories (or reestimate existing stories)
                      for emerging work, but that strikes me as artificial. If a particular
                      story turns out to be significantly more (or less) work we are not
                      really changing the business value of the original story and so adding
                      or removing business value is not the correct response. We need a way
                      to reflect the increase or decrease in work. Task hours are a
                      reasonable way to do this.

                      The preceding notwithstanding, I know teams can work effectively
                      without a sprint burndown. In that case I have no issues with them not
                      using a sprint burndown, but I'm not sure I see the value in tracking
                      stories or story points remaining. In my view stories and story points
                      apply to a different planning horizon (i.e. the release planing level)
                      and are chiefly concerned with tracking accumulated business value.
                      The sprint burndown is something different.
                      >
                      > Tobias
                      >
                      >
                      >
                      >
                      > That's all.  Keep it as simple as you can.
                      >
                      > --- On Wed, 10/29/08, thomas strandenaes <thostr@...> wrote:
                      > From: thomas strandenaes <thostr@...>
                      > Subject: [scrumdevelopment] What to put in the sprint backlog, and
                      how to use burndown chart ideal lines
                      > To: scrumdevelopment@yahoogroups.com
                      > Date: Wednesday, October 29, 2008, 2:48 PM
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      > Some scrum coaches suggest that team member activities
                      in a sprint that are not related to product backlog items (like
                      vacations) should be put into the sprint backlog as items, and burned
                      down as the sprint progresses. In this way the team will seem to stay
                      closer to the ideal line in the burndown chart even during team member
                      vacations, and team member absences are visualized to the team.
                      However the team will seem to be burning down work even when team
                      members are on vacation when using this suggestion, and the sprint
                      backlog is 'polluted' with non product backlog related work.
                      >
                      >
                      >
                      > What seems to be a more common suggestion is to subtract vacations
                      and similar from the team capacity during sprint planning and keep
                      these activities away from the sprint backlog entirely. If using a
                      straight ideal line in the burndown chart (not corrected for varying
                      team capacity), the team may however think they are on track in the
                      sprint until the team member vacation starts, and then never recover
                      completely during the sprint/not be able to meet their commitment, as
                      the ideal line assumed constant capacity throughout the sprint.
                      >
                      >
                      >
                      > What is the group optinion on using burndown chart ideal lines,
                      related to the two practices described above? and how do you handle
                      abscence like vacations and other activities that not related to the
                      sprint, in relation to the sprint backlog?
                      >
                      >
                      >
                      > I prefer to keep vacations and similar out of the sprint backlog, as
                      I want the burndown chart to show product item related burndown only.
                      I think using ideal lines in the burndown charts can confuse teams
                      into believing they need to stay close to this line at all times -
                      which obviously has no value in it self since work and sprint backlog
                      items naturally will emerge and change in the sprint in somewhat
                      unpredictable ways.
                      >
                      >
                      >
                      > Best regards,
                      >
                      >
                      >
                      > --
                      >
                      > Thomas Strandenaes
                      >
                      >
                      >
                      > ____________ _________ _________ _________ _________ _________
                      >
                      > Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
                      >
                      > notisblokk. http://no.mail yahoo.com
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.