We appreciate the potential benefits of custom statuses but feel that for the majority of teams, those benefits are outweighed by the advantages of simplicity. Of course, the world isn’t always as simple as open, resolved or closed. So Sifter has a few other features designed specifically to complement these fixes statuses. In designing Sifter, we have always had Conway’s law in the back of our mind.
…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
It’s as if there’s an inherent gravitational pull towards complexity. It’s attractive, and it tries to sneak in at every opportunity. Unfortunately, complexity doesn’t just end with software. The fallout from complexity can be far-reaching and go far beyond the confines of software. Fighting complexity is an ongoing struggle. A little here, a little there, and before you know it, everything is a mess.
Naturally, there are teams that truly need this level of complexity in their workflows. However, our experience has been that for the majority of small teams out there, that complexity does more harm than good. We certainly don’t expect NASA to start using Sifter any time soon, but we feel that simple is best for most of us.
The Complexity Monster
Custom statuses create complexity, and complexity doesn’t add up; it multiplies. Custom statuses require configuration. Configuration requires some preliminary thought about the different states. Too many different states, and people get confused about which state is right at which time. That leads to more thinking or asking about which status is right. Too many statuses can also lead to overclassification and organization fragmentation. When that happens, issues slip through the cracks. All of these things compound and create a variety of problems.
A Distinction without a Difference
If you look at the diagram, you’ll see that all Sifter has really done is do away with the multiple levels of distinction within each status. For instance, “accepted” or “assigned” are implicit. We just assume that all issues are accepted. If they aren’t accepted, then they need to be resolved and closed as such. Similarly, if an issue has an assignee, it’s been assigned. There’s no need to double up on that classification. We’ve shared our thoughts on why “on hold” and “pending” can create problems of their own. And finally, something is implicitly “in progress” if it’s open and assigned. Adding a status to capture that information is not only redundant, but tedious.
Track All the Things
If a set of statuses is overly specific, then more statuses can remove flexibility. “Working as Designed” may be a good status for a reported bug, but it’s not a very useful status for less-technical things like issues, questions, or action items. For instance, if you create an issue for your team to discuss which payment provider the team should choose, “Working as Designed” simply isn’t a relevant option. Worse, it’s downright awkward. Add in a few more statuses, and things start to fall apart.
If those other data types don’t fit, you’ll likely end up spreading data out into dedicated apps for tracking that information. Once that information lives elsewhere, complexity goes up dramatically. You’ll need to search two locations. You’ll have to constantly go back and forth to link items. Some things will be filed in the wrong application and have to be moved manually. It can get ugly. Having a single location for bugs, issues, questions, tasks, etc. can be surprisingly powerful. Nobody has to ask “where you should I report this?” or “where did we put that?” Everyone just knows.
No Configuration
We’re huge proponents of minimal configuration. There are only a handful of settings in Sifter, and we already feel like that’s too many. The goal of an issue tracker is to get work done, not fiddle with knobs and overclassify everything. In theory, the extra control sounds great, but in reality, it quickly becomes more of a burden than a benefit. Designing a set of statuses isn’t easy. Every team and every situation is different. Spending time, and possibly even meetings, designing a workflow can be a huge distraction.
On the surface, it may seem like simply choosing some words and putting them in order, but outside of the software, workflow is much messier. Issues move forwards and backwards and side-to-side. They get passed around and discussed.
Complementary Features Fill the Gap
In Sifter’s case, categories, milestones, and projects can be used to handle different statuses. For instance, internally, we keep a separate “Ideas” project that’s kind of like a dumping ground for conversations. Some of those issues eventually get promoted to the “Sifter” project where we’re actually writing code. You can think of that project as a backlog or icebox, but it’s really much more than that. It’s a safe zone for ideas to percolate while we’re staying focused on our active projects.
Similarly, milestones can help determine whether something is under active development. If it’s not in a milestone, it’s not happening. Whether you want to consider that “On Hold” or “Pending” is totally up to you. Another common request is for an “In Progress” status, but to us, that just sounds like more work to explicitly maintain a piece of information that should be implied based on assignment. If an issue is assigned to someone, it’s safe to assume that it’s effectively in progress. If it’s not assigned, or not in a milestone, then it’s not underway.
The Paradox of Choice
On the surface, it seems like additional statuses can only be more helpful. Unfortunately, more statuses also means more complexity which means more choices. It introduces room for statuses to overlap which leads to confusion about which status is the correct status for an issue.
The Sifter interface is explicitly designed around the simplicity of three statuses. Once you add more statuses, that means more colors, more space, and more complexity, which makes it more difficult to create a simple and easily comprehensible interface. The result is added confusion and complexity that gets in the way of getting work done.
An issue is always either going to be open, resolved, or closed. Always. Knowing those three states you can quickly and easily classify where the issue should be. Once you add more layers, it requires a little more thought to classify an issue. Having to stop and think about such things slows things down. The quicker everyone can move issues along the better it is for everyone.
Resolutions are Outcomes, not States
It introduces a temptation to use statuses to classify facets of issues that are best captured elsewhere. For instance, a lot of people want to capture resolutions as a status when resolutions are generally best captured in the description. Things like “working as designed”, “won’t fix”, “user error” all describe outcomes, not states.
On top of that, short resolutions are generally bad resolutions. “Working as designed” doesn’t explain anything or answer any questions. Resolutions should be detailed and helpful. They’ll either help the person reading it now, or they’ll be useful as an in-depth explanation for you two or three months down the line when you need the historical information. Resolutions work best when they’re written. “Closed” isn’t a a resolution. It’s a state that issues arrive at due to a resolution.
Easy Enough for Non-technical Folks
Understanding the different level of statuses becomes even more difficult to the outsider who submitted an issue and wants to track its progress. Open, resolved, and closed, leaves only a little room for interpretation, but when you add more steps, that process becomes a bit cloudy.
As a result, people who aren’t deeply versed in a custom workflow can easily mis-classify things. Or worse, they can be put off from the system simply because the process feels overwhelming. When people aren’t submitting issues, there’s not amount of custom statuses in the world that will help the workflow. Sifter was built to get issues reported and moved through quickly, but that breaks down in a complex system.
Summary
While three statuses won’t work for everyone, we feel that simplicity brings some great advantages. As with any decision, there are tradeoffs, but the majority of the time, for the majority of teams, the benefits of simplicity will far outweigh the potential perceived benefits of additional statuses.