No Points for You!
Other posts in this series about Story Points:
A very specific topic regarding Story Points from my AgileAI experiment was whether we should estimate work on defects and technical debt using points.
Should defects be assigned story points?
Should we point tech debt?
Starting with bugs, this one’s easy:
Back in 2006, Ron Jeffries, who was the original XP coach on the original XP team at Chrysler, spoke about defects being negative features. Defects take away from the team’s time and ability to deliver work that’s considered truly valuable to the consumers of that work. As such, they shouldn’t be counted as “progress” towards delivering that value.
The other argument against estimating defects using any method is that, when presented with a defect, we usually don’t know what we don’t know. It could take 2 hours to find the problem and 5 days to fix it, or 5 days to find the problem and 2 hours to fix it! There are exceptions, of course, such as a simple typo, but the vast majority of defects fall into this bucket of unknown and unknowable size.
I do recommend that you prioritize defects and have something like a “hit list” of top defects that the team should work on. I’ve done this a number of times, having the teams pull the top 1 or 2 defects from that list into their iteration. Yes, that will reduce the team’s capacity to deliver valuable work, but you need to consider that defects are a “tax” on delivering value.
So, no, do not under any circumstances try to estimate how long it will take to fix defects. Just work on them as needed. Ideally, when a defect is spotted, the team just fixes it immediately.
I will offer a caveat here, though. I categorize defects in two ways:
Programming mistakes
Missing or misunderstood requirements
The first is where, as software developers, we just made a mistake. This happens all the time because we’re human. Automated tests help significantly with this, but even then they still find their way into code.
The second category is somewhat different.
If a requirement was misunderstood, it is indeed a defect. In many cases this just means that a story isn’t done yet. We may need to add a missing acceptance criterion to the story in order to complete it.
Similarly, through delivering a story we might discover that there was a requirement that no one had considered. This is something that happens quite frequently, because software development is, after all, a discovery process. We simply can’t know everything up front!
When there are missing acceptance criteria for a story and definitely when there was a missing requirement altogether, we may choose to write new stories to cover what’s missing rather than logging them as defects. When this happens, just handle the new stories the way you would any story! They should be refined, acceptance criteria provided, split if necessary and prioritized just like all the rest.
Technical debt is a term that, like refactoring, has suffered from what’s called semantic diffusion. Originally, Ward Cunningham provided a very specific definition of technical debt, but it has since come to mean pretty much anything that slows a team down. Please note that I don’t consider defects to be technical debt, but they can be the result of it!
Regardless, dealing with technical debt can be similar to dealing with defects. It may seem to be a no-value-added activity for the consumers of the work, but can be quite valuable to the developers and testers. Again, though, in many cases we don’t know what we don’t know when it comes to dealing with it. We may not realize how often a certain class is used throughout the code. We might not know the implications of updating to a newer version of a library. So, we’re again in the position where estimation is even less than an educated guess - we just don’t know enough to do it.
There are a couple of approaches to dealing with this, though. The first is to try an experiment using what’s called a Spike. The experiment is small - a day or so - and just enough to inform our decisions about how to proceed. Once that has yielded more information about how to deal with the issue, the team can schedule the work.
I would not, however, recommend estimating the work using Story Points.
Instead, consider the work “interest” on the debt accrued. By borrowing money you can buy something sooner (or larger) but you’ll have to pay it off with a certain amount of interest on every payment. Debt in code is almost never like a mortgage on an appreciating asset like house, but more like racking up charges on a high-interest credit card! Therefore, the interest charges will be higher and take more of your income to pay. To translate that metaphor back to code, your ability to deliver value to the consumers of your work is reduced by the interest you have to pay in dealing with technical debt.
So, rather than estimating the work to pay down debt, assume that you’ll need to take away some of the team’s capacity each iteration to work on in. If, for example, the team completes around 20 points of story work per iteration, start pulling in only 15 points and do some debt retirement work. Alternatively, there’s no rule anywhere that says you must keep iterating (sprinting) constantly, so take a couple of weeks after a release to focus solely on technical debt work. I’ve done this many times with excellent results!
You will encounter resistance to these ideas, though. Product managers want features, features and more features and the team is slowing down the delivery of them. Well, what happens when you don’t pay anything on your credit cards? Eventually your credit rating is adversely affected and you may have to declare bankruptcy! In software development, having to rewrite a system because the code is too difficult to work with is the equivalent of bankruptcy. Sound familiar?
Ultimately, though, dealing with technical debt or even just technical changes like updating to new libraries, etc., should be included as part of the work of completing stories. You don’t need separate items on the backlog for that work - it’s just what you do to complete stories. This quite often requires a change in how team thinks, from separating delivery and technical debt work to all of that work being considered delivery.
When you stop using Story Points for work like defects and technical debt, a team’s velocity will reflect how much value they are delivering vs. how much work they’re doing. That’s a good thing, because it can trigger discussions about how to reduce the non-value-added work in ways that increase value to the consumers in a sustainable way.
That has always been the goal of the different methods that fall under the Agile Software Development umbrella.