New Paradigm of Issue Workflow

The big rage right now is the Agile development process, which I do like. The thing that I don't like is the inadequacy of issue states. This isn't just an issue within Agile, but one that plagues every workflow. Is an issue done? is it done done? Is it verified? How about deployed? What does it mean to reopen an issue? I face many of these questions on a daily basis, not just from others, but from myself as well.

Some where, in a dungeon at our office is a spreadsheet printed out which has an explanation of each of our 50 different states an issue can be in. I've also been lucky enough to try out the Greenhopper Simplified Workflow which simplifies the number of states dramatically. But it still doesn't capture enough states of an issue.

Basic States

State	Description
Open	Nobody has started working on this issue
Reopened	The issue was done, but was not completed properly
In Progress	Someone is currently working on this issue
Resolved	Coding has been completed and the issue is done
Closed	This issue was not actually an issue and has been closed

And this is fine for a starting point, but I don't believe that this actually encapsulates an entire development groups effort. Let's start with a basic workflow, a developer picks up an issue, works it, then passes it to their QA. QA then tests it, and sets it up for a UAT after which the UAT is approved and the issue is completed. Once the issue is completed, then issue is pushed to staging/pilot/production. Let's think about the possible states here.

Workflow separating QA and Development

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done

Let's think about another workflow that might happen. Let's assume that an developer picks up an issue and works it but gets blocked on some other issue. Let's assume that he gets unblocked and completes the issue sending it over to QA. Now let's assume that QA gets blocked on another problem. After getting unblocked they push it over for a UAT which then gets approved and the issue is pushed.

Separated Workflow with blocked state

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
Developer Blocked	This issue is waiting on resolution of another issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
QA Blocked	This issue is waiting on resolution of another issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done

Adding Closed States

But wait, there are a few different end states and outcomes of a specific issue; let's list a view different outcomes from issues.

• Issue was deployed to production
• Issue was transitive (fixed by a different issue)
• We understand that this is an issue, but there are no plans to fix it
• This is actually how the product works, so it is not an issue

Let's address these issues one at a time.

Issue was deployed into production

This is obviously the state we want all of our issues in. This, to me, is the definition of Completed

Issue was transitive (fixed by a different issue)

This is a special bucket where there was no actual code that fixed this issue that applies to the issue itself. So we should have another state of Closed where we can indicate why we did not actually complete it.

We understand that this is an issue, but there are no plans to fix it

This is one of those states that I hate to admit exist, the "Won't Fix" syndrome. But here is the issue, we shouldn't have a separate state for that, instead we should reuse our Closed state indicating why we didn't complete it. Communication is key, and this forces us to indicate why we aren't fixing it rather than just saying "no, we're not fixing it."

This is actually how the product works, so it is not an issue

This is a state in which we have to say "this is how this feature was designed" and I think that this falls into the previous section as well. Let's reuse our Closed state and indicate why we didn't complete it.

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
Developer Blocked	This issue is waiting on resolution of another issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
QA Blocked	This issue is waiting on resolution of another issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done
Closed	No code was changed in this issue, and no further action will be taken on it.

Transitions

The idea is that an issue can move between any two states at any time except from a closed state. An issue cannot be reopened. But why not? Why shouldn't we be able to reopen the issue that was closed?

Reopening Issues (the bane of our existence)

Let's think about what is means when an issue is reopened. If an issue is being reopened, this means that a user feels that the issue was not actually completed correctly. However, if we look at the stages of the issue and what it means to be Completed, then what the user is saying is "I don't think, QA tested this right and our Product Owner didn't understand the requirements."

If we accept that is what reopening an issue means, then we can see that the issue was not implemented completed, but instead that the underlying people did not do their job appropriately. In this case, we should not say that the issue was incorrectly implemented and should be redone, but instead we should address the issue with the people and create a new issue to rectify the incorrect implementation.

But what does it mean to reopen a Closed issue? It means that the user feels that we've ignored their request and that we really don't care about their issue. But, for the most part, we're saying "I'm sorry, but that's not in the cards." As such, we should do our best to communicate why it's not going to happen. We shouldn't just put a single sentence saying "Not going to happen" but instead, link to another issue or some other piece of documentation which explains why we're saying no.

A New Paradigm

Although I'm not saying that Agile doesn't work, I think that we, especially as organizations, become to involved with how many states there are to hold different people accountable. And in the end, only a very few people understand what all of the individual states actually mean. That being said, we should also be able to give more information to our users in order to make them feel better about the actions we take on an issue.

My paradigm is to take more time to update issues and flush out reasoning behind the outcome of the issue so that things like Reopened can go away. That coupled with the 10 states listed in our table below will provide developers and QA a simple process of moving issues between states with more freedom and fewer questions like "is this a Won't Fix or Invalid?"

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
Developer Blocked	This issue is waiting on resolution of another issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
QA Blocked	This issue is waiting on resolution of another issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done
Closed	No code was changed in this issue, and no further action will be taken on it.