Why I Don't Point Agile Bug Tickets

February 7, 2022

When I create Agile bug tickets, I leave the story points blank. Why? Two reasons: pointing bugs creates the wrong incentives, and bugs are hard to estimate.

Bug Terminology

First, some context.

Pointing is an Agile process of estimating how long a piece of work will take, or how complex it is. Bugs are defects in a computer program that produce undesirable behavior. And so, pointing bugs means trying to estimate how long it will take to fix a bug, or how complex it is.

Software engineering managers don’t like bugs, and like knowing when they will be fixed. Pointing the bugs would seem a solid way to achieve both, and yet, it often isn’t.

I developed this opinion at Hashrocket. There, we used Pivotal Tracker, the Agile project management tool. I believe that our opinion came from Tracker itself, which disables points for bug tickets by default.

Here’s how they explain that choice:

“By default, only features can be estimated with points. You can check this box to enable estimating bugs and chores, but we recommend against it, and it’s very difficult to reverse. If a story will provide immediate business value, make it a feature. Bugs and chores are an ongoing overhead for projects, but generally aren’t included in project velocity.” –‘Changing project settings’

Pointing Bugs Creates Backward Incentives

The previous block quote mentioned “ongoing overhead”– what does that mean?

Bugs are part of software. We want less of them. Some bugs matter. Some don’t. You’re never going to ship a product without bugs, and you’ll never fix every bug.

This is what Tracker means by “ongoing overhead.” Bugs are unavoidable, a cost of doing business, and some must be fixed.

There’s a saying in manufacturing: “That which gets measured, gets improved.” If you reward programmers for the lines of code added, you’re going to get PRs that add lots of lines of code.

This saying highlights the problem with pointing bugs. Bugfixes don’t represent business value or a competitive advantage. Following our previous logic, allowing bugs to contribute to a positive metric, velocity, should increase the number of bugs (or at least, bug tickets) that get created. Why? Because we get rewarded for fixing them. Instead of the byproduct of development, bugs become grist for the mill like any other work.

Here’s an example: a team launches a release that encompasses 100 story points of complexity. They point bugs, and along the way, they introduce 100 points worth of bugs. Post-launch, they spent the same amount of time on bugfixes as they spent on development. Velocity remains constant. In the opinion of management, the process is working.

Except, it isn’t! A 1:1 ratio of coding to bugfixing is far from ideal. Pointing the bugs created this incentive and the resulting behavior.

Bugs Are Difficult to Point

Bugs are difficult to point.

If you didn’t anticipate the bug while coding, then the bug is a blind spot for you. As a result, you’re not primed to fix it. In legacy codebases where you didn’t write much of the code, the problem could be much bigger than it first appears. Or smaller. Either way, you’re going to be wrong, a lot.

Conclusion

We’ve talked about:

Bug terminology
Why pointing bugs creates backward incentives
Why bugs are difficult to point

Managers need a clear picture of velocity. Pointing bugs doesn’t clarify that picture. I think it’s okay to leave it out.