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

Re: [scrumdevelopment] Don't burn the last day?

Expand Messages
  • Ken 'classmaker' Ritchie
    Hi Jean, you ve piqued my curiosity! Can you say a little more about their context? Why might they be motivated to edit their burn? What can you tell us
    Message 1 of 16 , Sep 28, 2012
    • 0 Attachment
      Hi Jean, you've piqued my curiosity! 

      Can you say a little more about their context? Why might they be motivated to "edit" their burn? What can you tell us about their cadence? Sounds like review & retro occur inside their sprint time box. How many days/sprint? How long do R&R take? What else happens on R&R day? Any slack time? Do they observe other teams' R&R's? Also wondering... When do backlog grooming and sprint planning occur? Who participates in the planning? 

      Cheers,
      --Ken ;-)

      Ken Ritchie (Atlanta, GA)
      404-216-3333 cell+text 
      678-392-2048 desk 
      Classmaker (SM) 


      On Sep 28, 2012, at 17:28, "Jean Richardson" <jean@...> wrote:

       

      I’m working with a Team that uses one of the more ubiquitous tools to track their sprints and roll up with about 35 other Teams for enterprise reporting.  This one Team is interested in editing their burndown so that the last day (Review and Retro day) is removed from the burndown because “we don’t really do any work that day anyway.”  

       

      I’m thinking of all kinds of reasons this would be a bad idea.  Has anyone ever seen this be to the good?  Anyone aware of sources that talk about this particular choice?

       

      --- Jean

       

      <image001.jpg>


      Jean Richardson

      Azure Gate Consulting

      ~ Repatterning the Human Experience of Work

       

      AzureGate.net

      (503) 788-8998

      Jean@...

       

       

       

    • rupesh raghavan
      Hi Jean, This generally happens when the team updates amongst themselves in the following manner during standups- 1. What I did YESTERDAY 2. What I will do
      Message 2 of 16 , Sep 28, 2012
      • 1 Attachment
      • 1.1 MB
      Hi Jean,

      This generally happens when the team updates amongst themselves in the following manner during standups-
      1. What I did YESTERDAY
      2. What I will do TODAY
      3. Blocks.

      Instead the team should adopt the below patter-
      1. What I did since the PREVIOUS STANDUP
      2. What I will do until the NEXT STANDUP
      3. Blocks.

      Now, if we have the daily scrum standup in the morning, then the team would have an update to share even for the review and retro day as they had a good part of the previous days update to share amongst themselves.

      If the daily standups are towards the end of the day, then the team would not have an update for the  review and retro day as it has already been shared by the end of the previous day.

      Please refer to the manual burndown attached herewith. Here the blue line is the ideal burndown and the red line is actual. Note that the ideal burndown is flat for the first day of the sprint as we have the standups in the morning. If the standups are kept for the end of the day then the ideal burndown would begin on Thurday and end of the 2nd Tuesday of the sprint(flat line on the last day of the sprint).
      Generally, the team has a stand up before they get into the review meeting to complete their burndown. The remaining tasks(if any) are carried forward to the retro and planning if required.

      In either cases, we will have 9 standups during the sprint.

      Hope my mail clarifies. :)

      Regards,
      Rupesh
      CSM, PSM I



      From: Jean Richardson <jean@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Saturday, September 29, 2012 5:28 AM
      Subject: [scrumdevelopment] Don't burn the last day?

       
      I’m working with a Team that uses one of the more ubiquitous tools to track their sprints and roll up with about 35 other Teams for enterprise reporting.  This one Team is interested in editing their burndown so that the last day (Review and Retro day) is removed from the burndown because “we don’t really do any work that day anyway.”  
       
      I’m thinking of all kinds of reasons this would be a bad idea.  Has anyone ever seen this be to the good?  Anyone aware of sources that talk about this particular choice?
       
      --- Jean
       
      Description: gate.site.jpg

      Jean Richardson
      Azure Gate Consulting
      ~ Repatterning the Human Experience of Work
       
      (503) 788-8998
       
       
       


    • Cass Dalton
      The burndown chart is a presentation of information. It is a tool to understand the team s progress. It is one of Scrum s information radiators. Removing the
      Message 3 of 16 , Sep 30, 2012
      • 0 Attachment

        The burndown chart is a presentation of information.  It is a tool to understand the team's progress. It is one of Scrum's information radiators.  Removing the last day from the burndown doesn't change the actual information, it changes how you present it. In fact it removes a small level of info.  What is the value of not displaying this info?  The team feels better about the lack of perceived value added on the last day? Management feels better about not getting perceived value on the last day?  Both of those are psychological benefits that are only benefits because of how the burndown is bent presented.  Removing the last day from the report will not change what happens on the last day.  Maybe each story meds to have a "prepare for demo" task to show the value that is actually generated on the last day.
        Scrums power comes from the brutally honest visibility.  If you start getting into the habit of decreasing the visibility because of how uncomfortable the presentation of information makes people feel, you may find yourself degrading much more important information radiators.

        On Sep 30, 2012 1:20 PM, "Tina" <colemanserious@...> wrote:
         

        Agree that burndowns are gross measures...  The idea is: are we on track to meet what we committed to...  When folks start debating what "counts" in the point estimate, how to factor, etc, there's an incentive to keep looking for ways to make the number more "real".  Bleah.  It's not a "real" number.  Spending "real" time arguing what goes into a non-real number is a "real" waste of energy, as well as detracts from the objective of delivering real business value as a team.  


        Tina

        On Sun, Sep 30, 2012 at 9:49 AM, Jean Richardson <jean@...> wrote:
         

        Andrew –

         

        I don’t think this team is competitive with other teams in the organization.  I *think* they’re trying to get a more accurate burndown, but, frankly, the trend has been pretty clear on their burndowns in the past.

         

        Avi –

         

        “Useless” might be a strong term.  Burndowns are relatively gross measures.  The trend on their burndown is a pretty accurate reflection of their actual delivery.

         

        This team, overall, has a tendency to concentrate on details over getting started:  Their user stories have evolved into mini-BRUP, including implementation notes, designs, and test plans before the team is willing to story point.

         

        That aside, I’m interested to hear about anyone having experience with, for instance, dropping day 15 from the burndown in a three-week sprint.  All things considered, has anyone seen value here.

         

        It may be interesting to note that this team is one of 38 teams in the org, and they are all using the same tool to track their sprints.  This team is the only one that would deviate.  We have the latitude to optimize process locally, and if org pushback comes down along the lines of “this will mess up our reporting at the exec level,” I’d be happy to stand up to that.  However, it seems to me that if this IS a good idea, why aren’t we all doing it?  I don’t know that I’ve seen discussions on this previously.  Have we all just missed something?

         

        --- Jean

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of avinap77
        Sent: Saturday, September 29, 2012 5:36 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: Don't burn the last day?

         

         

        Hi Jean.

        Sounds like your team got a good point - if the final RRP day is entirely taken up by the RRP activities, it should not be included in their capacity-planning either.

        The sprint burndown should be a very simple means of tracking ideal-vs-actual progress throughout the sprint. For that it neads to be realistic, including only the real work days. For that means, I would not include weekends in it either. Only actual work days ("business-days") available for producing code during the sprint.

        Including the last (non-working) day in the burndown will probably bring on negative pressure to achieve unrealistic goals, inhibit team success and demotivate them or at least render the burndown quite useless.

        HTH,
        Avi

        --- In scrumdevelopment@yahoogroups.com, "Jean Richardson" <jean@...> wrote:
        >
        > I'm working with a Team that uses one of the more ubiquitous tools to track
        > their sprints and roll up with about 35 other Teams for enterprise
        > reporting. This one Team is interested in editing their burndown so that
        > the last day (Review and Retro day) is removed from the burndown because "we
        > don't really do any work that day anyway."
        >
        >
        >
        > I'm thinking of all kinds of reasons this would be a bad idea. Has anyone
        > ever seen this be to the good? Anyone aware of sources that talk about this
        > particular choice?
        >
        >
        >
        > --- Jean
        >
        >
        >
        >
        > Description: gate.site.jpg
        >
        >
        >
        >
        > Jean Richardson
        >
        > Azure Gate Consulting
        >
        > ~ Repatterning the Human Experience of Work
        >
        >
        >
        > AzureGate.net
        >
        > (503) 788-8998
        >
        > Jean@...
        >


      • Mark Levison
        Oddly enough I ve long recommended not using the sprint burndown for exactly reasons you mention. To many teams focus on the ideal line. I suggest anytime I
        Message 4 of 16 , Sep 30, 2012
        • 0 Attachment

          Oddly enough I've long recommended not using the sprint burndown for exactly reasons you mention. To many teams focus on the "ideal" line. I suggest anytime I see a team with an ideal line I have to go digging fit the dead bodies.

          Cheers
          Mark

          On Oct 1, 2012 12:58 AM, "Jean Richardson" <jean@...> wrote:
           

          Avi –

           

          You’ve pretty much hit it on the head with this.  Except, the burn doesn’t magically track the ideal line.  Actually, the burndown chart reflects the Team’s progress, which isn’t always ideal.

           

          Much of what I’m seeing in response about dropping out holidays and so forth indicates to me that part of the problem here is the tool and using a tool in a standardized way across the enterprise.  This, in fact, may not be necessary.

           

          Interesting discussion.

           

          --- Jean

           

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of avinap77
          Sent: Sunday, September 30, 2012 1:42 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Re: Don't burn the last day?

           

           

          Jean - first of all to your question:

          > I'm interested to hear about anyone having experience with, for
          > instance, dropping day 15 from the burndown in a three-week sprint.
          > All things considered, has anyone seen value here.
          >

          I as a SM teach my teams the burdowns should **not** include days in which they are unavailable to burn down tasks. Your RRP day sounds like that kind of day.

          Mostly I work in 1 week sprints, where the RRP takes up only half of the last day, so we **do** include that day in the burndown.

          However on rare occasions when the RRP day does not leave any time for coding, we do not include it in the burndown. Likewise we do not include mid-sprint holidays, weekends etc.

          Our rule is the burndown only includes "coding days".

          We plot actual work left at the beginning of each day, so in day 1 the "actual work left" line stands on the same line as "ideal work left". As the sprint progresses, the actual work left line will be either above or below the ideal line, allowing the team to ask themselves "are we on track? do we need to rescope? what's keeping us? what can we do to reach the ideal 0 in the end?" etc - introspective questions for the team to keep focus on progress towards the sprint goal.

          In the final day the actual line "should" be roughly around 0, but honestly - we usualy don't bother looking at the burndown in the last day since it doesn't really matter by then. If the work isn't near completion everyoe knows it without the burndown, and it's too late to do anything about it anyway..

          Apart from that I see a strong pshychological effect of the burndown on teams. It visualizes their journey towards the goal as an incremental set of daily bite-sized steps. If the ideal line hits zero in a way that can be imaginabally realistic to them, it can help motivate the team and overcome fear. It gives them that "yes we can!" reassurement. If on the other hand it hits zero on a non-working day, everyone knows it's not realistic and the team sets themselves up for failure in advance. That's why I think *including* your last RRP day would be a bad idea. It's just likely to demotivate the team.

          ... which brings me to some other thoughts about your team, I hope I am not imposing myself here:

          * You mentioned they have a hard time getting started and need the assurance of big up front planning. This reads as anxiety and fear of failing to me.

          * You also mentioned their burndowns seem to (magically?) match the ideal lines. If the ideal lines hit 0 on non-working days, how can this even be possible? someone must be bluffing here..

          * The team doesn't seem to have the authority to decide upon their own burndowns? Does someone else decide about that for them..?

          * The burndowns are managed in an enterprise-level tool for 38 teams. I would imagine some kind of non-teammember-management is looking at their burndowns, maybe even comparing burndowns between teams. Even if this doesn't really happen, it doesn't take too much paranoya for a team to think it does and feel scrutinized. The burndown should be for the team and the team alone. They should feel protected and safe to use it in an honest manner for as long as it helps them achieve their goals.

          If any of those thoughts hit reality it sounds like that last day in the burndown is the least of their problems. I would try working with them on feeling protected, allowing failure, maybe drop some of the "training wheels" like the burndowns or the up-front-planning. Help them feel successful and secure on a small story, and then reinstate the burndowns as an aide for bigger stories - but only once they are mature enough to use it in a manner that is **useful to them**.

          BTW I remember an occasion with a team when the actual line wasn't moving down at all - it was a terrible sprint, everything was taking longer than estimaed, new unplanned tasks were popping up, burndown hell. By mid sprint the team was just gazing at the burndown with that "ok, let's just lay down and die" look.. At that point I suggested to them to stop using the burndown altogether since it was just making them feel bad. even stop using their taskboard. Just keep their eye on the ball (the sprint goal) and focus on nothing but the immediate next step towards completion. They ended up achieving that goal big time! go figure.. :)

          Sincerely hoping any of this helps,
          Avi

          --- In scrumdevelopment@yahoogroups.com, "Jean Richardson" <jean@...> wrote:
          >
          > Andrew -
          >
          >
          >
          > I don't think this team is competitive with other teams in the organization.
          > I *think* they're trying to get a more accurate burndown, but, frankly, the
          > trend has been pretty clear on their burndowns in the past.
          >
          >
          >
          > Avi -
          >
          >
          >
          > "Useless" might be a strong term. Burndowns are relatively gross measures.
          > The trend on their burndown is a pretty accurate reflection of their actual
          > delivery.
          >
          >
          >
          > This team, overall, has a tendency to concentrate on details over getting
          > started: Their user stories have evolved into mini-BRUP, including
          > implementation notes, designs, and test plans before the team is willing to
          > story point.
          >
          >
          >
          > That aside, I'm interested to hear about anyone having experience with, for
          > instance, dropping day 15 from the burndown in a three-week sprint. All
          > things considered, has anyone seen value here.
          >
          >
          >
          > It may be interesting to note that this team is one of 38 teams in the org,
          > and they are all using the same tool to track their sprints. This team is
          > the only one that would deviate. We have the latitude to optimize process
          > locally, and if org pushback comes down along the lines of "this will mess
          > up our reporting at the exec level," I'd be happy to stand up to that.
          > However, it seems to me that if this IS a good idea, why aren't we all doing
          > it? I don't know that I've seen discussions on this previously. Have we
          > all just missed something?
          >
          >
          >
          > --- Jean
          >
          >
          >
          > From: scrumdevelopment@yahoogroups.com
          > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of avinap77
          > Sent: Saturday, September 29, 2012 5:36 AM
          > To: scrumdevelopment@yahoogroups.com
          > Subject: [scrumdevelopment] Re: Don't burn the last day?
          >
          >
          >
          >
          >
          > Hi Jean.
          >
          > Sounds like your team got a good point - if the final RRP day is entirely
          > taken up by the RRP activities, it should not be included in their
          > capacity-planning either.
          >
          > The sprint burndown should be a very simple means of tracking
          > ideal-vs-actual progress throughout the sprint. For that it neads to be
          > realistic, including only the real work days. For that means, I would not
          > include weekends in it either. Only actual work days ("business-days")
          > available for producing code during the sprint.
          >
          > Including the last (non-working) day in the burndown will probably bring on
          > negative pressure to achieve unrealistic goals, inhibit team success and
          > demotivate them or at least render the burndown quite useless.
          >
          > HTH,
          > Avi
          >
          > --- In scrumdevelopment@yahoogroups.com
          > <mailto:scrumdevelopment%40yahoogroups.com> , "Jean Richardson" <jean@>
          > wrote:
          > >
          > > I'm working with a Team that uses one of the more ubiquitous tools to
          > track
          > > their sprints and roll up with about 35 other Teams for enterprise
          > > reporting. This one Team is interested in editing their burndown so that
          > > the last day (Review and Retro day) is removed from the burndown because
          > "we
          > > don't really do any work that day anyway."
          > >
          > >
          > >
          > > I'm thinking of all kinds of reasons this would be a bad idea. Has anyone
          > > ever seen this be to the good? Anyone aware of sources that talk about
          > this
          > > particular choice?
          > >
          > >
          > >
          > > --- Jean
          > >
          > >
          > >
          > >
          > > Description: gate.site.jpg
          > >
          > >
          > >
          > >
          > > Jean Richardson
          > >
          > > Azure Gate Consulting
          > >
          > > ~ Repatterning the Human Experience of Work
          > >
          > >
          > >
          > > AzureGate.net
          > >
          > > (503) 788-8998
          > >
          > > Jean@
          > >
          >

        • Steve Ropa
          I m just a little worried that they are focusing on the reports and tools, as opposed to the working software. Here s another question for them-how would they
          Message 5 of 16 , Oct 1, 2012
          • 0 Attachment
            I'm just a little worried that they are focusing on the reports and tools, as opposed to the working software. Here's another question for them-how would they work and plan if they had NO burn down chart?

            Jean Richardson <jean@...> wrote:

             

            Yup, that’s the question.  Monday will be interesting.  Last I heard, they felt this would help them plan.

             

            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Steve Ropa
            Sent: Sunday, September 30, 2012 8:05 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] Re: Don't burn the last day?

             

             

            Hi Jean,

            I wonder, how would modifying the burn down help their understanding of what they are doing or need to do for a given sprint?



            Jean Richardson <jean@...> wrote:

             

            Andrew –

             

            I don’t think this team is competitive with other teams in the organization.  I *think* they’re trying to get a more accurate burndown, but, frankly, the trend has been pretty clear on their burndowns in the past.

             

            Avi –

             

            “Useless” might be a strong term.  Burndowns are relatively gross measures.  The trend on their burndown is a pretty accurate reflection of their actual delivery.

             

            This team, overall, has a tendency to concentrate on details over getting started:  Their user stories have evolved into mini-BRUP, including implementation notes, designs, and test plans before the team is willing to story point.

             

            That aside, I’m interested to hear about anyone having experience with, for instance, dropping day 15 from the burndown in a three-week sprint.  All things considered, has anyone seen value here.

             

            It may be interesting to note that this team is one of 38 teams in the org, and they are all using the same tool to track their sprints.  This team is the only one that would deviate.  We have the latitude to optimize process locally, and if org pushback comes down along the lines of “this will mess up our reporting at the exec level,” I’d be happy to stand up to that.  However, it seems to me that if this IS a good idea, why aren’t we all doing it?  I don’t know that I’ve seen discussions on this previously.  Have we all just missed something?

             

            --- Jean

             

            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of avinap77
            Sent: Saturday, September 29, 2012 5:36 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Re: Don't burn the last day?

             

             

            Hi Jean.

            Sounds like your team got a good point - if the final RRP day is entirely taken up by the RRP activities, it should not be included in their capacity-planning either.

            The sprint burndown should be a very simple means of tracking ideal-vs-actual progress throughout the sprint. For that it neads to be realistic, including only the real work days. For that means, I would not include weekends in it either. Only actual work days ("business-days") available for producing code during the sprint.

            Including the last (non-working) day in the burndown will probably bring on negative pressure to achieve unrealistic goals, inhibit team success and demotivate them or at least render the burndown quite useless.

            HTH,
            Avi

            --- In scrumdevelopment@yahoogroups.com, "Jean Richardson" <jean@...> wrote:
            >
            > I'm working with a Team that uses one of the more ubiquitous tools to track
            > their sprints and roll up with about 35 other Teams for enterprise
            > reporting. This one Team is interested in editing their burndown so that
            > the last day (Review and Retro day) is removed from the burndown because "we
            > don't really do any work that day anyway."
            >
            >
            >
            > I'm thinking of all kinds of reasons this would be a bad idea. Has anyone
            > ever seen this be to the good? Anyone aware of sources that talk about this
            > particular choice?
            >
            >
            >
            > --- Jean
            >
            >
            >
            >
            > Description: gate.site.jpg
            >
            >
            >
            >
            > Jean Richardson
            >
            > Azure Gate Consulting
            >
            > ~ Repatterning the Human Experience of Work
            >
            >
            >
            > AzureGate.net
            >
            > (503) 788-8998
            >
            > Jean@...
            >

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