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

Re: Burndown chart and adding and removing items

Expand Messages
  • Dennis van der Stelt
    Agreed! It s been very, very good for my teams that that they know what the sprint backlog is about and that it s not going to change. Also because of the fact
    Message 1 of 15 , Aug 24, 2011
    • 0 Attachment
      Agreed! It's been very, very good for my teams that that they know what the sprint backlog is about and that it's not going to change. Also because of the fact that I know product owners who will walk to the board and change priorities, add & remove items, etc... Chaos!

      If we're looking at the Shu Ha Ri part Jeff always talks about, we're most definitely at the Shu state. And from what I understand, you get into Ha state when receiving black belt. We're no where near receiving black belt! ;)

      Anyway, best advice I got in this thread was that we need to ask ourselves what we want to make clear using the chart. If our changes to it reflect that thought, it's okay. For us it's important to measure the flow or pace, not if stuff is done. So it's okay to get the chart up, as long as it goes down at a constant pace.

      Thanks for the advice!

      --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
      >
      > I pretty much think a high volume of scope and (product backlog item)ordering change within a sprint for any Scrum team is a very bad smell.  Maybe that's not what you're talking about. 
      >
      >  
      > -------
      > Charles Bradley, CSM, PSM I
      > Experienced Scrum Coach
      > Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
      > My blog: http://scrumcrazy.wordpress.com/
      >
      >
      > >________________________________
      > >From: Adam Sroka <adam.sroka@...>
      > >To: scrumdevelopment@yahoogroups.com
      > >Sent: Wednesday, August 24, 2011 4:49 PM
      > >Subject: Re: [scrumdevelopment] Burndown chart and adding and removing items
      > >
      > >
      > >
      > >
      > >Yes. Particularly if the rate of change is so great that it doesn't allow you enough time to get anything done. *However*, perhaps if information is coming in at too fast of a rate for you to respond to it then the answer is to figure out how you could respond faster rather than trying to turn down the volume. 
      > >
      > >
      > >On Wed, Aug 24, 2011 at 3:38 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
      > >
      > >
      > >> 
      > >>I mostly agree with Adam here, but as one loosens the boundaries on scope changes too much, the changes can descend into chaos and a really bad pattern that is hard to get out of.  A change here and there is ok, but changes every day... that's not really development -- that's more of an IT support kind of thing, which IMO, is not easily compatible with Scrum.
      > >>
      > >> 
      > >>-------
      > >>Charles Bradley, CSM, PSM I
      > >>Experienced Scrum Coach
      > >>Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
      > >>My blog: http://scrumcrazy.wordpress.com/
      > >>
      > >>
      > >>>________________________________
      > >>> From: Adam Sroka <adam.sroka@...>
      > >>>To: scrumdevelopment@yahoogroups.com
      > >>>Sent: Wednesday, August 24, 2011 4:28 PM
      > >>>Subject: Re: [scrumdevelopment] Burndown chart and adding and removing items
      > >>>
      > >>>
      > >>>
      > >>>
      > >>>
      > >>>P.S. and I think trying to constrain changes to only the end of the sprint is like doing synchronized swimming â€" only breath when everyone else does. That may look cool, but I'd rather be comfortable in the hole where we're all swimming. 
      > >>>
      > >>>
      > >>>On Wed, Aug 24, 2011 at 3:25 PM, Adam Sroka <adam.sroka@...> wrote:
      > >>>
      > >>>+1. 
      > >>>>
      > >>>>
      > >>>>Also, don't think of these changes in priority as a bad thing. Assuming you adopted Agile for a reason this is one of the main benefits of doing it: you get to learn as you go along so that you build the right thing and not just what someone imagined the right thing would be. 
      > >>>>
      > >>>>
      > >>>>In fact, I think we should celebrate this and avoid negative terms like "scope creep". This is evolution and it is what we want, because it leads to a better, more productive outcome than simply following a plan (I seem to remember that in the Agile Manifesto somewhere...) 
      > >>>>
      > >>>>
      > >>>>
      > >>>>On Wed, Aug 24, 2011 at 3:13 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
      > >>>>
      > >>>>
      > >>>>> 
      > >>>>>1) Correct.  I often coach teams to use a vertical line(representing sprint work added/removed) to indicate product backlog items added or removed from the Sprint.  I also coach them to make sure they have a conversation with the PO when this happens.  See this link for an example of this method:
      > >>>>>http://3.bp.blogspot.com/_Oqkv5zzx0UA/SJ9YsxQuT3I/AAAAAAAAAFE/U-GH_i8cLhA/s1600-h/Picture+4.png
      > >>>>>Notes:  I usually recommend teams hand draw their charts(on whiteboard if possible) so using this method is much easier when hand drawn.  I also suggest that, if the team so desires, they can draw an arrow to the scope change, and add some text like "Added Story #445-A" or "Dropped 'Delete Username' story".  
      > >>>>>
      > >>>>>
      > >>>>>
      > >>>>>This strategy seems to work very well for most teams, and can also be used on a Release Burndown chart as well.
      > >>>>>
      > >>>>>
      > >>>>>2) Same answer -- if you show the scope changes as vertical lines, IMO, that increases the transparency and makes clear what happened.  Adding notes with arrows makes it even more transparent.
      > >>>>>
      > >>>>>
      > >>>>>
      > >>>>>I'm not saying other solutions are bad -- but IME, this one gives the best ROI, where return = transparency and investment = simplicity + time to execute strategy.
      > >>>>>
      > >>>>> 
      > >>>>>-------
      > >>>>>Charles Bradley, CSM, PSM I
      > >>>>>Experienced Scrum Coach
      > >>>>>Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
      > >>>>>My blog: http://scrumcrazy.wordpress.com/
      > >>>>>
      > >>>>>
      > >>>>>>________________________________
      > >>>>>> From: Dennis van der Stelt <dvdstelt@...>
      > >>>>>>To: scrumdevelopment@yahoogroups.com
      > >>>>>>Sent: Wednesday, August 24, 2011 7:31 AM
      > >>>>>>Subject: [scrumdevelopment] Burndown chart and adding and removing items
      > >>>>>>
      > >>>>>>
      > >>>>>>Hey there,
      > >>>>>>
      > >>>>>>I currently have Team A that was completely done with the sprint backlog and still had one-and-a-half-day left. So they chose some additional stories with the product owner. I reckon the burndown chart goes up a bit first and then completes anyway before the end of the sprint. Correct or not?
      > >>>>>>
      > >>>>>>Second question. I also have a team
      > where the product owner thougth of a specific item on the sprint backlog and removed it. Simple because it wasn't needed anymore. Now that team immediately drops the 8 storypoints that story was estimated as, resulting in a burndown chart that seems to go really, really well. But while it's doing good, it's not doing _that_ good. How to go about this?
      > >>>>>>
      > >>>>>>Thanks in advance!
      > >>>>>>
      > >>>>>>
      > >>>>>>
      > >>>>>>------------------------------------
      > >>>>>>
      > >>>>>>
      > >>>>>>To Post a message, send it to:  scrumdevelopment@...
      > >>>>>>
      > >>>>>>To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      > >>>>>>
      > >>>>>>
      > >>>>>>
      > >>>>>>
      > >>>>>>
      > >>>>>>
      > >>>>
      > >>>
      > >>>
      > >>>
      > >>>
      > >>>
      > >
      > >
      > >
      > >
      > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.