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

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

Expand Messages
  • Steve Ropa
    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@...
      >

    • Show all 16 messages in this topic