Issue trackers considered harmful

Issue trackers are great at what they were built for. Namely, tracking bugs. But using them for tracking a product development workflow has a lot of issues, perhaps not widely known in the tech community.

Most product development frameworks, like Scrum and Kanban, will focus on deliverables and outcomes for customers. The Scrum Guide focuses on this as 'incremental progress.' Kanban was built around the idea that you can visualize your workflow and discover bottlenecks by tracking how bugs fixes and features evolve from start to finish.

Anyone that has read "Empowered" by Marty Cagan or followed Gergely Orosz , John Cutler, or almost any other product development evangelist will know that teams focusing on delivering impact and on outcomes instead of just being told what to do offers significantly better value, are happier in their jobs, and are instrumental in helping companies become successful.

But, if you look at most software development teams' issue trackers, they are full of tasks. Except in the cases where the deliverables are small (like bugs or minor improvements), the issues don't represent the outcomes we want for our customers; they represent tasks for individuals. And they are not used to track the entire development flow. All the work done before it becomes an engineering task is not tracked. Some issue trackers will recommend these anti-patterns in their "methods," and no wonder since that is what their tool was designed to do.

John Cutler is one of many that have observed that teams fall into traps when visualizing their workflow. For most tech companies, software development is a cross-functional collaboration between product management, design, and engineering. An excellent product development team not only builds the features but is also instrumental in figuring out what to build, shaping the roadmap, and operating the software, in addition to coding and fixing bugs.

That is where keeping your visualization at a task or issue level breaks down. We should be focusing on what we plan to deliver to our users, regardless of the size. This is at the center of “outcome” before “output”

One can easily ask, "why can’t issues represent outcomes?" They can, but they are not designed for it, and the issue trackers don't try to help you do that. Issues typically have only one assignee. They don't give you ample space to describe the problem and solution, so teams are spec'ing or shaping outside the tool where they track the progress. Issue trackers focus more on metadata and workflow than on supporting the team in collaborating, reaching decisions, and shipping to our customers. Some issue trackers will even actively suggest scoping issues to be as small as possible, which is the opposite of what a sound product development framework will suggest.

So, what can be done to fix this?

First, we should be aware of the shortcomings of the issue tracker. Already using one? Then you should probably shift your focus to your outcomes and the tasks and issues you have. A whiteboard, Notion, Coda, or Trello are tools that can complement your issue tracker and ensure you always keep an eye on the bigger picture. The challenge is that you will end up tracking work in two systems.

Some issue trackers have the concept of Epics or projects that can help you track higher-level things inside the same tool. That can be useful, but the problem is still that they are 'issues first.' The tools will constantly nudge your team to focus on tasks or issues daily, not getting the right stuff out the door.

We figure that there had to be a better way, and as a result we built Kitemaker. As far as we know is the only tool built specifically to help development teams work in a way that they can focus on outcomes. It enables us to create a tool where the specs, tasks, and discussions all live in the same place. And by using our integrations, team members can see all relevant discussions and activities regardless if they happen in a communication tool, a design tool, or an engineering tool. For our customers, this has enabled a significant shift in how teams work, by replacing a task/ticket-focused way of development with having the team caring and focusing on shipping the right things to their customers.

So, if you are looking for a way to make it easier for your team to be involved in shaping the product and shift from a task focused to an outcome way of working, why not check out Kitemaker, and tell us what you think?