In addition to an “On Hold” status, one of the other common requests with Sifter is an explicit “Accepted” or “Verified” status. While these are important steps in the issue life cycle, Sifter is designed to handle these without cluttering the status list. Based on our years tracking issues and conversations with customers, there are a few reasons why we felt that “Accepted” or “In Progress” are overkill for the majority of teams.

More Steps

The primary purpose of having an “accepted” (or “verified”) state is to ensure that issues are valid and that the right person is working on them. “Accepted” generally indicates approval of a new feature requeest or something that would otherwise likely be out of scope. “Verified” is used as a way of saying “this is a legitimate and reproducible issue.” In either case, it’s used as a gating method to ensure that someone should work on it before a developer gets underway.

This kind of workflow generally requires that a project manager or team lead review and assign all issues. For most teams, the process of approving or verifying an issue goes hand-in-hand with assigning the issue to someone that will work on it. So now instead of just setting the assignee, you also have to remember to update the status. If you don’t update both, the issue might slip through the cracks. It’s an extra step that creates extra room for mistakes.

Redundancy & Overlap

In addition to the extra work, having some sort of approval state is essentially redundant with planning or assignment. For instance, within Sifter, if an issue isn’t assigned to a milestone, it’s considered “Unplanned.” Similarly, if it doesn’t have an assignee, it’s considered “Unassigned.” To help enable this workflow, Sifter supports unassigned issue notifications so that issues don’t slip through the cracks while they’re unassigned.

If an issue is unassigned or unplanned, it’s implicitly not accepted or verified. So, by adding a status to communicate this state, we’d be creating a level of redundancy, and potentially ambiguity. For example, “It’s assigned to Milestone X, but it hasn’t been accepted.” Ambiguity like this hurts momentum because now someone has to both request and wait for clarification.

Lack of Flexibility

Sifter is designed to track more than bugs. So every additional state in the process needs to work equally well for questions, ideas, issues, bugs, or anything else that needs to be tracked. So, say a client logs a generic question about a business decision as opposed to a bug or issue. That question now needs to be either “Accepted” or “Verified”. Neither of those are a very good fit, and “verified” is downright awkward. The workflow loses it’s ability to comfortably support differents types of issues.

As an extension of this, there’s a difference between features (scope creep) and bugs. With features, having an explicit approval process involving a project manager makes a lot of sense whereas with bugs, it’s pretty simple. They need to be fixed. So in this case, it may be tempting to want the explicit approval process for feature requests, but that same process can inhibit progress on questions, issues, or other non-feature request items. So, instead, it’s best to design workflow and educate your team to recognize feature requests and then reassign those issues to a project manager before beginning work.

This requires placing some trust in your team to recognize potential scope issues and pass them to a project manager, but this way, there’s no bottleneck on the majority of issues. This way, you can accept everything and design your processes to filter out the thing that don’t belong. This flows nicely into an arguably more philosophical reason against explicit acceptance states, but one that is just as imporatnt.

Rejected by Default

The underlying weakness of having an explicit state for accepting issues is that it assumes the glass is half empty. That is, it believes that by default issues are not valid. In this case, we’ve found it’s best to simply look at the odds. Let’s say that 80% of issues are valid and 20% are invalid. That 20% could be duplicates, an out of scope feature request, unreproducible, or have some other issue. If the large majority of issues are valid, it’s overkill to treat them as invalid by default. It’s more efficient and effective to design your workflow to remove or reorganize the invalid issues than to explicitly approve every single issue that’s created.

Let’s say that you’re working with clients or internal non-technical stakeholders, an explicit acceptance state essentially says “by default, we’re going to assume your issue is invalid.” That may not seem like a big a deal, but it sends a very clear message and arguably creates an Us vs. Them mentality. Instead of implicitly rejecting everything by default, it’s easier to single out the items that should be rejected. This way, the obviously acceptable items can pass right on through, and you have an opportunity to provide an explanation when items are rejected.

Having an explicit state for acceptance and verification may be necessary for some larger teams with complex workflow, but for most teams, it’s a formality that we can do without. Hopefully with these considerations and workflow tips, you’ll be able to be more productive, and accepting, than ever without any negative impact on productivity.