Deferred status, resolution or version?

[Andrei [errno]]

I am looking for a best practice here.
QA team repeatedly comes to our JIRA team asking to add a "deferred" status.

I could argue that if we add a status - we'd need to build a more complex workflow and we'd need to build in more logic to store the previous status, so we could "resume", etc.

So I am always recommending a "deferred" fix-version, so no other fields/statuses are touched, but the issue is not showing up in the TODO lists, and can still be queried for "planning for the next release" purposes.

what do the gurus usually do for "deferred"? thanks in advance

[Andrei [errno] · Accepted solution]

thanks for your suggestions, but I went with "deferred" fix-version after all.

[Jobin Kuruvilla [Adaptavist]]

My recommendation is to go for a new status - just what the QA requested. I agree that the workflow will have to be modified but that is the whole point.

There are advantages of doing it in a workflow. You can limit who can do that, do post functions like setting values, clearing fields, assigning to someone automatically etc, validate on some fields... You might not be needing any of these now but this is just the beginning ;)

Moreover, it isn't exactly a fixVersion if you ask me!

[Nic Brough -Adaptavist-]

I agree with Jobin. I constantly point out that one of Jira's strengths is that it goes a long way to making the software fit your process, rather than the usual "we have software X, we have to fit with that" approach which demonstrably doesn't work. (Something I learned from a book on computing history - "A computer called Leo", which I'd recommend if you're interested in that sort of history)

You should always consider workflow changes in a generalised way - does the request help make Jira work better for a lot of your users? If so, it's probably worth implementing. I resist ones that will only be used by a tiny handful of people, or feel like a bodge, but if it matches your process, and a new status is the best way to do it, then go ahead and do it.

In this case, you've got a lot of people asking for it, and you've obviously thought through the other ways you might want to do it and found them lacking. So I'd recommend adding it to the workflow.

[Andrei [errno]]

thanks for your comments, guys. I trust your opnion.
For an argument sake - having deferred as a version will also let me "release" a version without any unresolved issues left behind = clean. I really do not see any other use in our environment, but just being able to filter these out for status reports.
I may be wrong though, have been wrong a lot of times. I was right a lot of times too:)

[Jobin Kuruvilla [Adaptavist]]

You can do filtering based on status too. So that shouldn't be an issue. Regarding "releasing" a verison without any unresolved issues, that can still be possible when the status is deferred. Actually, it gets only confusing when you use it as a fixVersion I guess?

One more things to add here is that you can configure JIRA to remove th current fixVersion when you set the status to deferred. And on resume, you can have the fixVersion on screen and make the user add one! Just another suggestion.

[Norman Abramovitz]

I did things alittle differently for our deferred implementation. A deferred issue means to us that no more work will be done now. It is not a closed issue either since the work could be restarted later. So we added a new resolution field value called "deferred" and resolved the issue. The version field is not set since it is not scheduled for release.