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

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

Expand Messages
  • 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 1 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 2 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 3 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.