Two Reasons Why I Don’t Point Agile Bug Tickets

February 7, 2022 - 4 minutes read - 644 words

When I create Agile bug tickets, I don’t add Agile story points. In this post, I’d like to explain this preference via two arguments: pointing bugs creates backward incentives, and bugs are surprisingly difficult to point.

But first, some terminology and history.

Bug Terminology

Pointing is an Agile process of estimating how long a piece of work will take, or, depending on who you ask, 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. Software engineering managers don’t like bugs, and also like knowing when they will be fixed. Pointing would seem a solid technique, and yet I’m going to against it.

Origin of the Idea (For Me)

I developed this opinion at Hashrocket. There, we used Pivotal Tracker, the timeless 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? Seasoned technologists know that 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 except in the most trivial of applications.

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. Reward the number of tickets closed, and you’re going to get a lot of tickets opened and closed.

This 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 that get created. Why? Because there’s no penalty 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 previously spent on development. Velocity remains constant, and 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. Instead, we should steal from manufacturing, pull the Andon cord, and find the sources of the defects.

Bugs Are Difficult to Point

Secondly, bugs are hard to point. If you didn’t anticipate the bug while coding, then the bug is likely 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 much smaller. Either way, you’re going to estimate incorrectly a lot.

All pointing is fraught, to the point where some teams don’t point at all. But bug points are uniquely unreliable.

Wrapping Up

We’ve talked about:

Bug terminology
Where this opinion came from
Why pointing bugs creates backward incentives
Why bugs are difficult to point

Giving management a clear picture of velocity is important, and pointing bugs counter-intuitively makes that harder.