Jake Worth

Why I Don't Point Bugs

Published: February 07, 2022 2 min read

  • debugging

I generally don’t add Agile story points to a bug ticket and in this post, I’d like to explain this preference. I’ll cover terminology, genesis of the idea, how pointing bugs creates backwards incentives, and why bugs are hard to point.

But first, some terminology!


Pointing is an Agile process of estimating how long a piece of work will take, or how complex it is. It’s used to estimate when something will be done.

A bug is an error or flaw in a computer program that produces undesirable behavior.

And so, pointing bugs would be trying to estimate how long it will take to fix a bug, or how complex it is.

Source of the Opinion

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

Here’s their explanation of this 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’

This seems to be the source. So, ongoing overhead— what does that mean?

Ongoing Overhead

Seasoned technologists know that bugs part of software. We want less of them. We try new techniques to produce less bugs. Some bugs matter and some don’t. You’re never going to ship a product without bugs.

This is what Pivotal means by ongoing overhead: bugs are unavoidable, and some must be fixed.

Don’t Measure Bugs

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.

This highlights the problem with pointing bugs. Bugfixes don’t represent forward-moving value. Allowing them contribute to a positive metric, velocity, will increase the quantity of bugs that get created. Instead of the byproduct of development, bugs become material for the machine like any other work.

As an example, a team could launch a release that encompasses 100 story points while introducing 100 points worth of bugs, then spend the same amount of time on development as bugfixes. Velocity remains constant, so to management the machine is working.

But, it isn’t. A 50/50 mix of coding and bugfixing is far from ideal. Instead, we should pull the Andon cord and find the source of the defects.

Hard to Point

Lastly, bugs are hard to estimate. If you didn’t anticipate the bug while coding, then the bug is by nature a blind spot for you.

Wherever the mistake was made, 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.

All points are fraught, but bug points are uniquely unreliable.


Giving management a clear picture of velocity is important, and pointing bugs makes that harder. I’m holding onto this opinion until a better one comes along, and I hope this post has explained it well.

✉️ Get better at programming by learning with me. Subscribe to Jake Worth's Newsletter for bi-weekly ideas, creations, and curated resources from across the world of programming. Join me today!

Blog of Jake Worth, software engineer in Maine.

© 2022 Jake Worth.