Most of us prefer to spend our time developing new features for our customers. But we usually have some overhead in the form of bugs and chores that takes some of our time. Since Tracker started out life on greenfield projects, it has a default setting that bugs and chores don’t get point estimates. The idea is that bugs and chores emerge over time, and while they do take time to address, they’re an ongoing and fairly consistent cost.
Some Tracker users want a way to make the size of a bug story or a refactoring chore visible to the customers. Some have a need to show how much time is spent each iteration fixing bugs and dealing with infrastructure. Some of the people who want point estimates for bugs and chores also still want a separate velocity that relates to new features only, as a planning aid. Tracker’s default velocity calculation focuses on business-valued output in the form of feature stories only, making it simpler to predict project milestones, and adjust them when feature scope changes.
But can there be business value in bugs and chores? Should they have point estimates? Should they have point estimates that don’t “count” towards project velocity, or that have their own separate velocity? Do they account for themselves over time if they aren’t given points? These questions are up for discussion, not only in the Tracker community, but in the larger Agile community.
There’s even an ongoing debate about whether bugs should be tracked at all, or simply fixed right away in a test-driven manner and forgotten. Similarly, there are differing opinions on how to manage technical debt and keep infrastructure up to date. Some teams devote so many story points each iteration to infrastructure activities. Some, including my own previous team, have an iteration devoted solely to reducing technical debt every few months. Others accept that bugs and chores are an ongoing cost and must be done in order to maintain a steady, predictable velocity.
Speaking from my own experience over the years, I’ve found that bugs which are too complicated or difficult to fix immediately are best turned into feature stories. We have to put some thought into them to prevent future problems from recurring in the same area. Similarly, when we educate business experts about the value of keeping our infrastructure up to date and our technical debt at a manageable level, they can make an informed decision when setting priorities. Doing this on my previous team allowed us to maintain a predictable velocity that helped the business plan ahead. Our low technical debt also let us react quickly to new priorities. I know other teams who used different approaches but achieved similar success. As with so many software development practices, there’s no “one right way.”
When I advise teams how to decide on the practices that are best for them, I normally suggest they do small experiments. Try a practice or approach (preferably the simplest one) for a couple of iterations, evaluate how that worked, and try new experiments as needed until you find what’s right for your team. A team working on a legacy web application with legacy bugs may have different needs than one with a greenfield embedded software project.
If you turn on the ability to estimate bugs and chores in Tracker, but decide later that it’s not working well for your team, it’s quite painful to reverse that decision. So, try other techniques first. Use bugs and chores as is and see if, over time (and remember, it takes a long time for a new team to achieve a steady velocity) they average out as a “cost of doing business.” If that’s not providing the right visibility and planning ability, try creating feature stories with point estimates for the more complex defects and activities to maintain infrastructure or manage code debt. Try a “fix and forget” approach to bugs instead of tracking them. Try tracking bugs and chores in their own separate projects.
Use your retrospectives to see if there’s a wider or more basic issue at the heart of the discussion. It may be more useful to invest in ways to prevent bugs from occurring in the first place, or to try different development frameworks or infrastructure solutions.
We’d welcome your feedback about how to track bugs and chores. If you’ve found ways to minimize this type of overhead or more useful ways to handle them, please let us know.
Category: Productivity
Tags: How to
