Estimating defects and tech debt – should we?

This is a good follow on to the velocity and capacity discussion. If velocity is the amount of new feature work we can get done in a sprint and capacity is the amount of bandwidth we have in the sprint, other stuff fills in the delta between velocity and capacity. SO…do we estimate it?

It depends. If people do not understand the distinctions between velocity and capacity and see them as the same thing we need to be very deliberate about the numbers we are communicating. Each sprint has a mix of items in it. We need to ensure we differentiate between those items so we understand the type of work we are doing and how it is relating to our goals.

If we estimate all our work, we need to discuss the difference between our new feature velocity (used for roadmap forecasting) and our “other items” velocity. Adding the two together gives us our total capacity. Looking at them separately gives us and idea of what is in our sprint and release mix.

If we choose to only estimate our only new feature work, the idea of two different velocities goes away. We’re only putting estimates/numbers on the work we’re going to use to forecast our releases. The other items we can look at as either a percentage or a count. Instead of putting estimates on defects, let’s just assume that they will overall average out to be similar size therefore let’s just count the number. We can do 50 story points of new features and 5 defects each sprint. But what about the tech debt and other work?

Tech debt can be difficult to estimate, however, in our velocity discussion I think that tech debt should be road-mapped along with our new features. In that case, I would estimate it. So instead of:

Velocity = new feature work

instead

Velocity = planned roadmap work

We’re planning it with our new features in sprints after all. And if we are not, how is that impacting our product quality? We need to balance the new features with the stability and sustainability of our code. If we ignore tech debt and allow it to pile up, we will have to pay a larger opportunity cost later piled on with a cost of delay that our customers feel with issues and then longer lead time to new features. So let’s add it to our roadmap for the release and sprints!

Defects by definition are super hard to estimate. And really, if they are prod defects that escaped, technically they should have been included in that story estimate. Now, if they have not yet been released to production or escaped the sprint, those should not be estimated because they are part of the story! The story isn’t DONE until all the defects are resolved – it’s included in that story work.

So should we estimate them?

Honestly, I do not care. Just be consistent. If you estimate them, estimate them. If you don’t, don’t. But make sure you have a way of understanding, visualizing, and communicating the count or percentage of defects in each sprint, both planned and unplanned so you can better forecast the planned work. It’s really that simple.