Re-booting our Issue Tracker to Focus on Priorities
This post describes a different way of using issue tracking, which we we currently use at GitPrime. It has has worked better for us than a traditional approach, and we’ve found it to be particularly effective at catering to our needs as a location-agnostic engineering team.
Instead of thinking about the issue tracker as a process, we have focused on setting up our Kanban board as a way to maintain shared priorities in a way that keeps everyone in sync. This has significantly reduced the need for communication to happen in real time, which works well across our distributed time zones.
The issue tracker has become a core part of how our team communicates, with a few guideposts:
- Abandon the traditional process/accountability use case
- Focus exclusively on using Trello as a priority-tracking system
- Be disciplined in restricting tickets to truly relevant work items
Columns and categories reflect our priorities
The first thing we did was get clear about development priorities, independent of any specific features or tickets. Like many teams, our priorities tend to shift a bit, so we made sure to account for this when thinking structurally about what’s important. This ended up being a 3-tier set of priorities that look like this:
Tier 1: User-Blockers
The first and most important tier is anything that gets in our users’ way. This might be a confusing part of our UI, a bug for which there isn’t an obvious workaround, or any other issue that gets in the way of user success.
These always take priority over anything else.
Tier 2: Quick wins
The second tier is all about pragmatism, and is reserved for things that are cheap to fix (from an engineering perspective) and high-value for users. As an example of this: at one point we had a series of requests from users to change the successful log-in screen of our app to something more valuable. In this case, implementing a “more valuable” screen was pretty minor (some flat HTML and minor edits to routing logic), and was a near-unanimous desire on the part of our early users.
Since this was a quick win for users, it got queued up under Tier 2. Internally, we defined “cheap to fix” as anything that takes roughly a half day or less.
Tier 3: Product Roadmap
The third and final tier is our product roadmap. As a product owner, it can be a bit painful to see this take ‘last place’ in a tiered system. Practically speaking, however, any item that truly belongs in Tiers 1 or 2 is going to be something that users will thank you for fixing before launching the latest and greatest app feature.
Tier 3 items also tend to be larger & more involved tasks, so it’s a good idea to clear a path first by cleaning up any outstanding Tier 1–2 issues.
Tier Nothing: Everything Else
All other work gets rejected on principle. Some examples of things that get rejected:
- administrator-level functionality that does not directly support unblocking (customer) users
- non-critical UI upgrades that don’t get in the way of core functionality
- feedback from users that we haven’t quite refined into a concrete, & actionable set of changes
So our board for Engineering looks like this:
Things still move left-to-right, but this isn’t really a ‘process’ so much as it is a continual opportunity to kill tickets, whether that happens by accomplishing them or rejecting them. Fresh tickets start in triage, and are sorted based on whether they actually fit into a Tier 3, 2, or 1. If not, they are rejected. If they sit there too long, they’re also rejected.
Since we use this as a tool for communicating priorities instead of an accountability tool, there is no expectation that individual developers keep this up to date other than to communicate with other engineers to avoid ‘work collisions,’ which serves to helps prevent instances of pure-process-mania like this:
Things That Make This Work
There is a ‘rejected’ column
One of the columns we maintain is a ‘rejected’ column, which we use liberally. While ticket rejection happens often, there are really only 3 reasons for it:
- Insufficient requirements
- Doesn’t fit our 3-tier priority model
- The ticket is too old
Out of these, perhaps the most unusual is (3) — we have a tendency to reject tickets in principle once they get past a certain age. Anything over about a month old comes under scrutiny. This has been a pretty healthy practice: a month is a long time in software, and oftentimes a ticket has become wholly out of date.
Maintaining a formal column for rejected tickets (where issues typically sit for a few days before getting purged) gives stakeholders ample opportunity to freshen up the ticket or fill in any details that might have caused the rejection.
While a bias toward rejecting tickets might seem extreme, this has let us keep our issue tracker tidy, and has the effect of structurally ensuring that we’re working on things that matter. This bias toward rejecting tickets — combined with trust that any truly important items will eventually resurface — has been very successful in continually focusing developer efforts where they truly make the most impact.
The issue tracker only contains work-ready items
Another important piece of this is the decision to limit our issue tracker to only items which are work-ready. This is perhaps the most aggressive decision, as the bar for ‘work-ready’ is pretty high. An issue is work ready only when it fits all of the following criteria:
- Stakeholders have agreed it should be built
- Requirements are detailed enough that implementation can start immediately
- There are no outstanding prerequisites to the work that are outside of Engineering’s control
Keeping to this fairly strict definition of ‘ready’ has been very healthy: those three items, combined with a structural understanding of priority inside our Kanban board, means that Engineering can operate with near-complete autonomy.
When non-ready tickets find their way into the system (as sometimes happens) they are, of course, rejected under this set of shared assumptions. Note that there are broad classes of tickets that don’t exist in the engineering Ticketing system:
- There are no purely conceptual ‘idea’ tickets
- Suggestions without detailed requirements are rejected
- There is no ‘icebox’ or ticket graveyard to slowly accrue and consume brain cycles
- There are no tickets that require non-engineering intervention or additional business requirements to get started
Product managers and other stakeholders must track all of the above somewhere else outside of the engineering issue tracker. We’ve adopted the notion that all non-conforming ideas are simply not something that engineers should have to deal with in a half-baked fashion.
By default, only fully-formed requests merit engineering attention.
Advantages of this Approach
Speed: A chief advantage of all of this is that it allows engineering to move fast. There’s quite a bit less ‘checking in’, and between our Kanban board and our own tooling around engineering visibility, we quickly got to the point where daily stand-ups were redundant. So we stopped doing them.
Autonomy: This approach also biases toward both developer autonomy, and autonomy of the engineering team in general. Since ill-formed requests are structurally rejected, the majority of what needs to be filled in tends to be implementation- & architecture-level details, which engineers can do with little to no stakeholder interaction.
Low Communication Overhead: This is perhaps implicit in the points above, but this is an extremely low-overhead way to work that is particularly effective for distributed teams. Most communication is ‘peer-to-peer’ and there’s little need for all-hands meetings.
Engineer Happiness: Most developers like to build cool stuff. Since this approach looks to maximize stuff-building, it tends to be more enjoyable for developers than going to meetings or running down requirements.
Disadvantages to this System
Stakeholder Discomfort: All of this definitely requires a non-trivial amount of stakeholder buy-in. It can be a bit disconcerting for product managers to see their tickets get rejected simply because they’re ‘too old,’ for example. Stakeholders need to be able to see the forest for the trees, and be generally in agreement that the momentum & quality of life gains are worth letting go of the occasional pet feature.
Product Owner Overhead: It should also be noted that this can somewhat increase the overhead for Product Owners/Managers. Since ill-formed to-do items can no longer be tracked on the engineering board, they need to be tracked somewhere else. This has a non-zero cost. Still, we’ve taken the opinion (as product owners ourselves!) that it’s better to cater to the engineering workflow and optimize there, even if this means we need to come up with new ways to track our users’ feature requests.
Admittedly, this whole approach is maniacally biased toward engineering — specifically, toward offloading all “non-engineering stuff” to people who aren’t developers. That has to be something that stakeholders in the business are okay with, which isn’t always the case.
It is for us, and we’ve found this to be a pretty solid approach.
When we adopted a priority-driven development strategy, it was when we stopped worrying about Trello and just started using it.
How has your team solved for this? Hit me up on Twitter
Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.