It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Deferred status, resolution or version?

Andrei [errno] May 16, 2012

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

3 answers

1 accepted

0 votes
Answer accepted
Andrei [errno] Feb 19, 2013

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

3 votes
Jobin Kuruvilla [Go2Group] Community Leader May 16, 2012

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] Community Leader May 16, 2012

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] May 16, 2012

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 [Go2Group] Community Leader May 16, 2012

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.

0 votes
Norman Abramovitz May 16, 2012

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.

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published in Next-gen

Introducing subtasks for breaking down work in next-gen projects

Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...

859 views 12 14
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you