Published: February 07, 2022 • Updated: January 23, 2023 • 3 min read
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:
But first, some terminology and history!
Pointing is an Agile process of estimating how long a piece of work will take, or how complex it is, depending on who you ask.
Bugs are defects in a computer program that produce undesirable behavior.
And so, pointing bugs means, more or less, trying to estimate how long it will take to fix a bug. Software engineering managers don’t like bugs, and do like knowing when they will be fixed. Seems like a solid technique, and yet I’m going to against it.
I developed this opinion at Hashrocket. There, we used Pivotal Tracker, the timeless Agile project management tool. I believe that our opinion came from Pivotal itself, which disables points for bug tickets by default.
Here’s their explanation of this decision:
“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’
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. We try new techniques to produce fewer bugs. 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 Pivotal 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 progressive business value. 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 and bugfixing is far from ideal. Instead, we should steal from manufacturing, pull the Andon cord, and find the sources of the defects.
Secondly, bugs are hard to estimate. If you didn’t anticipate the bug while coding, then the bug is by definition 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 miss the mark sometimes.
All pointing is fraught, to the point where some teams don’t point at all. But bug points are uniquely unreliable.
We’ve talked about:
Giving management a clear picture of velocity is important, and pointing bugs counter-intuitively makes that harder. I’d like to hear your opinion on Twitter.
Get better at programming by learning with me. Subscribe to my newsletter for weekly ideas, creations, and curated resources from across the world of programming. Join me today!