Why Estimate Bugs and Chores in Your Backlog?

When we’re running a client’s project using our Atomic Process, our team will assign an estimate of points to each item in the product backlog.

In general, we classify backlog items into three buckets:

• Features (new or enhancements)
• Chores (dev work not resulting in tangible product changes)
• Bugs (fixing unexpected behavior or regressions)

New teams commonly consider whether chores and bugs should be estimated using points.

When using Pivotal Tracker, this conversation rarely makes it past the realization that their backlog tool both disables estimating bugs and chores by default and labels the setting to do so as “Experimental” and “Strongly Discouraged.”

Tracker’s argument, paraphrased, is that bugs and chores are more emergent and do not deliver business value as features do. Therefore, to simplify planning, one should only focus on estimating the backlog items that deliver business value.

This simple rule is easy to accept, especially when building an MVP.

Nonetheless, I encourage all Atomic teams to check that box for their project and take a more nuanced approach to estimating bugs and chores.

The rule for the aforementioned approach is:

“If the intent is to finish the bug or chore this sprint, don’t estimate it. If it’s being placed in the backlog beyond the current sprint, estimate it.”

We do this because:
POINTS don’t represent VALUE.
POINTS represent COST.

There is no direct correlation between the cost of a feature and its business value. When a team estimates a backlog item, they are reasoning about its cost—i.e., how complex is this item to implement in terms of other items? 2x? 5x?

If we tell a client that only features deserve estimates because nothing else delivers business value, we draw a false connection between points and value. This connection is dangerous for two reasons:

1. It undermines the importance of understanding the business value of features independent of their cost.
2. It can encourage people to incorrectly correlate velocity to outcome instead of output.

The priority of a backlog item should be a function of its cost, risk, and value (business value or knowledge value).

Knowledge Value

Suppose a feature in your product backlog gets a very high estimate from your team. The team perceives the feature to be risky due to unknown viability of potential approaches, so to be responsible, they estimate the feature using their best guess for the most expensive option.

A good follow-up for a product owner in this situation would be to create a chore in the backlog for further investigation into the viability of the options for the feature. While this chore doesn’t necessarily add business value to the product, it does add knowledge value through a better understanding of the feature’s true cost and risk.

Noise vs. Planned Work

Emergent can mean either unexpected or needing to be taken care of right away. In the context of software development, when I hear someone use the term “emergent work,” I assume the former—work that has revealed itself unexpectedly.

The timing of discovering work shouldn’t determine whether or not it’s estimated. Rather, the way in which the team tackles the work should determine it.

Emergent work that arises unexpectedly during a sprint is noise if it must be completed before the end of the sprint. This noise will affect our signal, or velocity, likely by making it lower than originally expected for the sprint.

If tackling emergent work is deferred by prioritizing it into the backlog beyond the current sprint, it becomes planned work.

Once work becomes part of our plan, if working on it comes at a cost, that cost should be represented in our plan. This is why bugs and chores placed in the backlog beyond the current sprint need to be estimated.

Not estimating items in the backlog that have a cost leaves an undetermined shortage in the overall estimate to complete the project—your projection will be optimistic, and your project will likely go over budget or under-deliver on scope.