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

Re: Backlog provides visibility: does it belong here?

Expand Messages
  • chuckspublicprofile
    IMO, what you ve presented here is a viable, well thought out, and logical option, but I don t think it really provides a lot of value in your situation.
    Message 1 of 2 , Sep 10, 2008
      IMO, what you've presented here is a viable, well thought out, and
      logical option, but I don't think it really provides a lot of value in
      your situation. Here's why...

      If you start with the definition:
      "a measure of the teams capability at producing new
      increments of potentially shippable product every Sprint"

      It appears that you've assumed what is meant by "new increments" is
      new software/features. I don't know that this is necessarily true.
      Defining potentially shippable product is also a bit tricky(how do you
      account for trivial bug reports that were not part of the original
      acceptance criteria, and end up rolling into production?).

      DEFINITELY don't count it scenarios:
      If you're developing software from scratch, then maybe it's a good
      practice not to count bugs as velocity items. If we're speaking of
      bugs found against functionality developed in the current sprint, then
      they should DEFINITELY not count towards velocity. If you see people
      rolling bugs to a new sprint just because they can, then I say you
      DEFINITELY shouldn't count them either. You might even consider not
      counting bugs towards velocity if they were caught by an automated
      test that was regularly passing and all the sudden broke(probably by
      someone in the current iteration). In these cases, you're directly
      sacrificing quality in the current sprint or recently and taking on
      technical debt.

      However, in a more "legacy baggage" type situation, at least a few
      things are at play:
      1. Bugs might be the result of some developer/tester/customer who
      worked at your company months or years ago. Are you really going to
      let that affect today's team velocity measurement? I suggest not.
      2. "New increments" could include bug fixes... why not?
      3. I think of velocity as more of a rough measure of how much work a
      team can do in one sprint. If your team is using one of the above
      mentioned (DEFINITELY don't count it) scenarios, then you're not
      really measuring velocity of the current team. If your team is not
      sacrificing quality directly and currently, then why create drag on
      your velocity that's not accurate in portraying your team's true
      capabilities?

      In short, I guess what I'm saying is... I say definitely size the bugs
      on the product backlog, but only count them for velocity if the bugs
      are not a result of bad quality in the recent past. Of course, the
      sprint burndown chart is really only a measure of tasks for a sprint,
      so it's independent of the bug points issue.

      I can't help but wonder if maybe there's a way to divorce the quality
      measurements from story points altogether. Story points are assigned
      to size an effort in time, but I don't think by themselves they do a
      great job of measuring quality. Maybe a different measure of quality
      is more appropriate.

      Maybe I'm confused or missing something. Maybe there is an inherent
      definition of "quality" or "done" that is required to make velocity
      work like it should.

      Charles


      --- In scrumdevelopment@yahoogroups.com, "Mike Freislich"
      <mikefreislich@...> wrote:
      >
      > Hi all,
      >
      >
      >
      > My thinking at the moment is to add these items to the backlog, have the
      > team estimate them and mark them as "no-velocity". When I ask teams to
      > commit to work for a Sprint, I cover up the estimates and ask them
      to think
      > about the work involved. I review the estimated velocity once the
      commitment
      > has been made and reflect any major variances with the norm to the team.
      > Come Sprint Review, we can review what has been done, but the
      "no-velocity"
      > items do not contribute towards the velocity of the Sprint. The Sprint
      > Burndown should probably include these "no-velocity" items, because
      the team
      > is trying to get a sense of tactical progress during the Sprint.
      >
      >
      >
      > Your thoughts?
      >
      >
      > Mike Freislich
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.