One of the toughest problems in software development is figuring out what to do next. We can’t help you with the abstract version of that question, but it isn’t just the abstract question that’s hard. All of the software development teams we’ve talked to struggle with a version of this same question.

Knowing which work to do next is difficult. Period.

Every development team’s wish list is long. Let’s be honest—endless. This makes software development exciting but also overwhelming. What should you do next? Fix bugs? Ship new features? Improve security or performance? There’s no perfect science for calculating which is most important.

One thing we can tell you won’t help – keeping track of everything in separate groups or systems only makes the decision process more challenging.

A Distinction without a Difference

This can be counter-intuitive at first. For example, you’re probably used to tools and systems that have some things you call “bugs”, quantifiable shortcomings in software, some you call “issues”, potential problems that aren’t directly to related code like pricing or design decisions, and other things you call “features” or “enhancements” for ideas that haven’t been implemented yet.

Organizing tasks by category like this offers a comforting way to break things down. It makes us feel like we’ve done something, even if we haven’t. All we’ve really done is rename the problem. We still don’t have any better idea of what to do next or what’s most important.

If you’ve worked with such a system for long you’ve probably seen it fall apart. The boundaries between bugs, issues, and new features tend to be vague, and trying to make your tasks fit into an arbitrary category rarely helps us figure out what to work on next. Worse it forces us to classify everything in one of those categories even when the actual problem might be too complex to fit just one.

We’ve found that it can be even worse than just “not helpful”. If we separate tasks into variants of bugs vs. features like this, some tasks will implicitly become second class citizens. This problem is even worse if bugs and features are kept in separate systems. There is no such thing as separate but equal as separate is inherently unequal. In this case bugs will frequently take a backseat to new features. And shipping new features without fixing old bugs is a slippery slope.

Priorities vs. Categories

We’ve also found that the best technique for deciding what we should do next is not to organize issues by whether they’re bugs or enhancements, but to prioritize issues regardless of whether thye’re a bug or enhancement. Bug vs. enhancement is often used as a contributing factor for prioritization, but that’s just a proxy. The real underlying consideration is customer impact.

To determine priority we need to balance all possible tasks based on two factors: the positive impact on your customers and the effort it will take to complete that task. Priority isn’t much help without considering both impact and effort.

Establish a priority hierarchy for your tasks and you’ll never wonder what you should do next again. You’ll know.

Sometimes finding that balance between impact on the customer and effort expended is easy. A bug that affects 20 percent of customers and takes 5 minutes to fix is a no-brainer – you fix it, test and ship.

Unfortunately, prioritizing tasks is rarely this black and white.

What to do with a bug that only affects one customer (that we know of), but would take a full day to fix, is less immediately obvious.

What if that customer is our biggest customer? What if that customer is a small, but very influential one? What if our next big feature could exacerbate the impact of that bug? What if our next big feature will eliminate the bug?

There’s no formula to definitively know which task will be the best use of time. If the bugs are minor, but the next feature could help customers be more successful by an order of magnitude, our customers might be more than willing to look the other way on a few bugs.

There’s only really one thing that’s more or less the same with every decision: What a task is (bug, issue, feature) is much less important than the priority you assign it.

The classification that matters is “what percentage of customers does this affect” and “how long will it take to do this task?”

Categories & Workflow

That does not mean we should dump categories altogether. For instance, if we group tasks based on modules like “Login”, “Filtering” or “Search”, that grouping helps us identify related tasks when you sit down to work on a given area. In that case the categories become helpful because they help your team focus. Similarly, “Login” issues are likely to be higher priority than “Search” issues.

Workflow or module-based categorization can also help us gauge the relative health of a given area of the codebase. In this case, differentiating between bug vs. feature is nowhere near as valuable as differentiating and evaluating based on the priority of issues in a given category or module.

A bug might be classified as a bug, but it also means that a given feature is incomplete because it’s not working correctly. It’s a gray area where “bug” vs. “feature” doesn’t help teams make decisions, it only lets us feel good about organizing issues. It’s the path of least resistance and one that many teams choose, but it doesn’t really help get work done.

If you want to get real work done, focus your efforts on determining priority. Decide where the biggest wins are for your team by looking at the impact on your customers versus the time required to complete the task. There’s no formula here, but prioritize your tasks rather than just organizing them and you’ll never need to wonder what you should do next.