Wednesday, November 11, 2009

Should fixing bugs contribute to a team's velocity?

I get this questions often. I am sure you probably also got this question at one time or the other. There are two ways to look at this- value vs. cost. These perspectives are linked to how you define velocity. Let's look at both in more details.

Value perspective. If you define velocity as the net value (in story points) delivered to your customer, then you should not include bugs in your calculation of velocity. Think about it for a moment. Bugs are something that are not working as expected, but the customer has already paid for them. So, by fixing bugs you are not really delivering any "incremental value" to the customer. If you increase your velocity by including bugs, you are inflating your velocity. Now, granted that sometimes we report something as a bug when it is an incremental feature. You need to work with your product owner to negotiate to change those bugs into stories and account your effort for them in your velocity.

Cost perspective. If you define your velocity as the amount of work done by a team in a sprint, then you should include bugs in calculating velocity. Yes, bugs take effort and time to fix. Hence there is a cost associated with fixing bugs. But this makes the release planning a little bit complicated. Because you cannot know ahead of time how many bugs you may have until the release. Directly using velocity to calculate the effort or to determine the time-line for the release will most likely be off (undershoot). One way to address this is to break the velocity into two components- feature-delivery velocity, and bug-fix velocity. This is in a way going back to the first option.

I personally am in favor of using "value" perspective and exclude bugs from calculating velocity. This helps keep our eyes on the ball- delivering "customer value." As a result, we are encouraged to reduce bugs in the first place so that we can free up our capacity to deliver more value. That is why we currently do not allow users to point estimate bugs in ScrumPad.

Are you including your effort spent on bug fixing in your velocity?
Posted by at 3:33 PM
Labels: , ,
Reactions: 

6 comments:

  1. Hi Syed, great post. You can actually find a simple and sustainable solution based on the generic definition of Done. Imagine your product management (customer proxy) and quality assurance measures "accept" a demoed story, you ship it, meaning the story is done and released. Now in the unlikely case that your customer (project integration or end-customer) might be blocked by what turns out to be a serious priority 1 issue occuring under any unforeseen circumstance ... then you simply stop the belt. Area team fixes the blocking issue (to return story to done), then continues with new stories. Thus the operational quality teams provide to end-customers is one factor affecting sustainable speed. A further step to your lean and learning company. Cheers tjk
    ReplyDelete
  2. Hi Syed, great post. You can actually find a simple and sustainable solution based on the generic definition of Done. Imagine your product management (customer proxy) and quality assurance measures "accept" a demoed story, you ship it, meaning the story is done and released. Now in the unlikely case that your customer (project integration or end-customer) might be blocked by what turns out to be a serious priority 1 issue occuring under any unforeseen circumstance ... then you simply stop the belt. Area team fixes the blocking issue (to return story to done), then continues with new stories. Thus the operational quality teams provide to end-customers is one factor affecting sustainable speed. A further step to your lean and learning company. Cheers tjk
    ReplyDelete
  3. Thoralf,
    Good point. A team's velocity is also tided to its definition of "Done." Bugs are like speed bumpers on the road. More bugs, reduced velocity. Given a team's current maturity, the velocity adjust to a sustainable level.

    Thanks for your comment.
    ReplyDelete
  4. Syed

    you raise an interesting point, amd one worth considering.

    For my part i have historically included bug fixing as part of velocity, to many times new features are masked as bugs, and i want to use velocity to track and estimate the speed of my team not quality or accuracy.
    I do however let users decide to not accept a story as being completed (like thoralf has mentioned), I also track quality as the ratio of new work created from defects resulting from work created during an iteration.

    If a team completes 100 pts but generates 50 pts of bugs, then they get a quality score of 50 for the iteration..
    ReplyDelete
  5. Hi Jeff,
    So it seems you are doing the 2nd option. It is good that you are also tracking the ratio of bug to total velocity as a way to understand the quality of your team's work. This means that you are tracking velocity by bug and new features (NF). Do you use the total velocity or just the NF velocity to do your release planning?

    Thanks.
    ReplyDelete
  6. Syed

    On most projects I plan releases using one velocity number , taking into account an expected number of defects as a tax...
    ReplyDelete

Subscribe to: Post Comments (Atom)