In these situations a common question is whether the team should assign some number of story points to the work of fixing these legacy bugs.

If the team does not assign a story point value to this work, velocity will show the amount of “forward progress” the team is making each sprint. This has the advantage of making visible that the team is going more slowly through the work than it could if these legacy bugs had been fixed when originally found.

On the other hand, if the team does assign points to the bug-fixing effort, velocity comes to represent the team’s true capacity to accomplish work.

My usual recommendation is to assign points to the bug fixing. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish but also able to look at the historical data and see how much went into the bug-fixing story each sprint. Knowing this can be helpful to a team and its product owner. For example, imagine a situation in which the product owner is considering suspending bug fixing for the next six sprints in order to add a valuable different feature into a release. If we know that the team’s full historical average velocity was 25 but that 5 points went to bug fixing each sprint, we know that suspending bug fixing for the next six sprints will result in 30 (6*5) more points of new functionality.

But what about a bug found today in something the team wrote a month or a year ago? And what about the existing bug database that a team new to agile is almost sure to bring with them?

The ideal situation is to put the bugs right onto the product backlog. To see why, consider the situation from a user’s perspective: Do you think a user cares whether something is considered a New Feature or a Bug? No. The user just wants the system to behave in some way different from how it behaves today. They don’t care what it’s called.

But notice I called this the ideal situation. It isn’t always practical–and sometimes for reasons out of the team’s control or influence. Bug databases have a way of becoming embedded into organizations. The tech support group uses them as a primary way of communicating with the developers. The marketing group uses the bug database in a similar way. This makes it quit the bug database cold turkey.

In these cases, the most common solution teams use is to have two backlogs

• a product backlog of features
• a bug backlog

This approach is a bit harder on the team and the product owner but allows an agile team to work more easily with existing processes in the organization.

Sometimes when we make such accommodations to the overall organization, the accommodation can damage or destroy the agile adoption. Allowing everyone to work on five concurrent projects is an example of a crippling accommodation. Accommodating the organization’s use of a bug database is not crippling. It’s just a bit more work.

The product owner takes on most of the additional work by having to prioritize two separate work queues and then present them to the team in a more or less consolidated manner (“My top priorities are the first three items on the product backlog, then bugs #12403 and 12415, then these next two items on the product backlog…”). This isn’t too onerous as the items would need to be prioritized even if all were in one backlog.

So: Ideally bugs belong on the product backlog just like any feature request. But, that would often necessitate a significant change for the rest of the organization so two backlogs are used.

If you’ve been to one of my classes, heard me speak at a conference, or just poked around my website you very likely know that I have a strong preference for task boards whenever possible. Usually this means whenever a team is collocated or a few special distributed teams who want to do it. A taskboard will look something like this:

To answer the questions about storyless tasks, I want to answer in the context of using a task board. But the essentials of my answer will remain the same even if you are using a tool.

Most teams find it useful to include two additional rows on their task boards:

1. Miscellaneous
2. Bugs

Each other row on those boards represents a user story and the cards are the tasks to implement the story. The Miscellaneous and Bugs rows are essentially the storyless tasks. The Miscellaneous row holds things like “update the build server.”

I do not normally recommend that a team estimate these items in story points such that they would earn any points toward velocity by completing these tasks. Tasks in the Miscellaneous row are usually tasks that enable the team to perform the other work (or to perform it better or faster). It is reasonably safe that over the long-term any story points you’d consider assigning here will average out. This is yet another reason why I always stress that velocity is a useful long-term predictor rather than a predictor of the short-term such as what a team may complete in exactly the next iteration.

I often use a Bugs row on the task board for bugs that are either:

• discovered during the iteration but unrelated to the stories of the current iteration (bugs related to stories already on the board go into the To Do column of the story’s row)
• planned at the start of the iteration to be done during the iteration

If the bugs were planned into the iteration at its start, often a team does put a story point estimate on those bugs. Usually the bugs are estimated together–that is, “if we fix these 6 bugs we’ll get two story points.” Lots of teams with large defect backlogs plan to do something like bring in 5 points of bugs each iteration. So they estimate those a bit “backwards.” Rather than grab a stack of bugs and ask, “how many points do these 8 bugs represent in total” they keep adding bugs into the iteration until they feel they’ve brought in the desired number of points worth of bugs.