I was recently surprised by a question asking if technical debt should be considered a "chore" and subsequently, should it counted in your velocity or not? First, the term "chore" was completely new to me, and the idea that you would ever intentionally not track something in your velocity was equally foreign. Turns out both are concepts from a product called PivotalTracker, which I've previously never looked into. Turns out PivotalTracker has a very opinionated stance on this:
Feature stories are estimated because they contribute to business value. Bugs and chores are considered part of normal software product overhead—they emerge over time, and are continual overhead, an ongoing cost of doing business. Tracker’s automatic velocity calculation accounts for this as a built-in cost, and estimates how much business-valued work can be completed each iteration. This lets you focus your planning on business value, risk, and priorities. Therefore, bugs and chores in Tracker are not normally estimated.
To me, this is an abuse. A good tool should not impose a process on its users, but should rather empower its users to follow the processes that work best for them. Additionally, this type of subtle evangelism of process tends to imply that it's the way it should be done, despite the fact this being an acceptable approach is very much a matter of debate.
Rant aside, this prompted me to present what I think is a far better approach, and one that more closely aligns with the principles of Agile and Scrum: everything is a PBI.
A rose by any other name...
The thing is: naming does matter. What we call things affects our perception and our behavior. For example, Scrum has largely switched from the term "commit" to "forecast". Why? Well because when you commit to something, if you don't deliver, you failed. You broke a promise. You reneged on an oath. When you forecast something and don't deliver, well, you just try to forecast better next time. It's why people don't sue meteorologists, but they very must sue contractors who don't complete a project by a deadline.
When you have a term like "bug", the perception is that it's critical that it be fixed ASAP. It's also usually colored red, which implies that there's danger involved. The thing is, and this might be controversial, not every bug should necessarily be fixed. For now, I'm going to let that one ruminate; we'll talk more later.
Likewise, "chore" has to be the worst term I could imagine incorporating. Not only are we applying it to things like technical debt that has an inherent "chore" implication, but you've now labelled this thing as something you effectively never want to do. How often do you think developers on your team are going to willing go pick a "chore" to work on. Humans don't like chores. Chores are things we don't want to do but have to. They imply drudgery and pain, and we have a tendency to avoid them as much as possible.
"PBI" or "Product Backlog Item", on the other hand, is about the least offensive name possible. It honestly doesn't really mean anything. It's just something you might do at some point. It may be easy. It may be hard. It may be fun. It may be boring. It's Schrodinger's cat.
When everything is a PBI, then you have to look at other factors to determine the worth, which brings us to:
It's all about the Benjamins...
From an executive view, no one cares whether something is a feature, a bug, a chore, or something else entirely. All that matters is how it affects the bottom line. From an end-user view, again, what you call it is meaningless: all that matters is that their software does what they need it to do. If it does, then they keep giving your company money. If not, they move on to your competitor.
In other words, it's all about business value. How much value does this thing bring to the business? Will it keep customers happy and money rolling in? Will customers cancel if they don't get this? It's not all about customers, though. Will this thing allow us to iterate more quickly? Being fast to market can make or break a business, and anything that makes that more achievable has inherent value. Creating automated build and release scripts? That might be considered a "chore" by PivotalTracker with no business-value, but over here in reality, that's money in the pocket. It's an investment that returns dividends many times over.
When you free yourself from the terminology you empower yourself to focus on what actually matters: bringing value to the business. If something is a bug, but doesn't bring value to the business, guess what? Yep, it doesn't get fixed. The fact that it's a bug is totally inconsequential. If you have some technical debt and removing that brings value to the business, guess what? It shoots to the top of the list.
And it is part of your team's velocity...
Velocity is already a rough metric. It's based on how many story points you've been able to do in a sprint. Those story points, in turn, are based on how you sized the PBIs in your sprint, which in turn is based on how you've sized similar PBIs in previous sprints. In other words, it's an estimated based on an estimation derived from other estimations. It's something, mind you, and don't get me wrong: over time it can become very accurate if you're sizing PBIs correctly.
However, that's kind of the point. You need that data. You need to, as close as possible, know how much work you're actually burning through in a sprint, not just whether you managed to get some random amount of work done. That means everything needs to be sized. A bug or a chore isn't some magical thing that gets worked on at night by elves while developers are sleeping. It's a real, tangible unit of time that's being subtracted from a developers work day, and hence, their capacity for the sprint. Only by sizing it and including it in your velocity can you actually accurately gauge how much work is getting done. Otherwise, it's just a black hole.
Calling everything a PBI just makes this easier. It's then no longer a question of whether a bugs or "chores" get sized. PBIs get sized. Everything is a PBI. Everything gets sized. Then, you work on the PBIs that matter most to your business. Easy.