Working with “Storyless Tasks”

A question I get frequently is what to do with tasks that do not belong to a particular user story or product backlog item. Common examples I’m asked about include tasks like “update the build server to use the latest version of FitNesse.” Fixing bugs from prior iterations are another common example. I’ve sometimes heard of these tasks that don't belong to a particular product backlog item or user story referred to as “storyless tasks.”

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.