What counts as Velocity?

Recently we encountered a large-enough issue that required a postmortem (like a retro). One of the teams involved asked if they should put that into the sprint and give it points (ie. size it). This reminded me of a debate we encountered in our earliest days of implementing Agile.

One side insists that we only point planned stories that provide immediate, direct business value to the company. Therefore, things like defects, chores, and meetings should not get points assigned. The reasoning here is that these activities are typically not included because they may occur without consistency and predictability across iterations; while they are a necessary part of our project, they can be thought of as an ongoing cost of just doing business.

Pivotal Tracker (a fine issues-tracking tool) asserts in their FAQ that “by measuring velocity in terms of features only, [the tool] can estimate how much real, business-valued work can be completed in future iteration, allowing you to predict when project milestones might be achieved, and allow you to experiment with how any change of scope might affect such milestones.” So again, the focus is on business value, risk, and prioritization as opposed to the “constant drag on business-valued output”.

The other side argues that fixing a bug is just another change with no fundamental difference from a feature request. Ie, the application shows a certain behavior and someone wants it changed. Bugfixes and features are the same from a cost / benefit equation, and business types will evaluate them according to their given strategy.

Most teams at SendGrid do point bugs, some point chores as well. My feeling is that as long as the teams are consistent and the PO / business types are aware of this, then the impact of straying from “by the books” Agile/XP isn’t too concerning. Still, I’m interested in hearing how others deal with this, both the benefits and risks.

[ Here’s another link from Pivotal’s community board on the topic. Good read! ]

– – – – – – –

[Update from Feb 25]

We at SendGrid just made the change to not assign points from defects and chores. The decision was made at our all-hands Engineering Summit and was initiated by the developers. One big argument consisted of “Hey, our velocity has dropped to 3pts because we’re focused almost solely on bugs. Stop forcing the team to work on new features before we can clean up the tech debt from our previous efforts.”