Re: Backlog provides visibility: does it belong here?
- 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
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
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.
--- In email@example.com, "Mike Freislich"
> 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
> about the work involved. I review the estimated velocity once thecommitment
> has been made and reflect any major variances with the norm to the team."no-velocity"
> Come Sprint Review, we can review what has been done, but the
> items do not contribute towards the velocity of the Sprint. The Sprintthe team
> Burndown should probably include these "no-velocity" items, because
> is trying to get a sense of tactical progress during the Sprint.
> Your thoughts?
> Mike Freislich