We have just started to Greenhopper for a particular project. They are loving the Plan / Work approach.
There are a number of issues, which in the 'spreadsheet' Jira has replaced were marked as a Status "On Hold". These items are not to be developed in the immediate future.
What are people's recommendation for easily idenitfying these issues?
I don't know if you have seen this post:
The main issue against using workflow for solving this is in my opinion the need for knowing "when" an issue was put on hold. If you have a specific status for "on hold" you may need to store the status it was in when it was stalled so that you could resume it to the correct status. Otherwise you will have to move it through several statuses when resuming it. Therefore I think it is better to keep it in its current status and use labels instead.
Just some food for thoughts!
You make a good point and in fact I've come to a similar conclusion. The additional statuses we have discussed are to support addtional workflow - and would in some cases stop issues you that are not ready to be developed not being selected.
I actually like the idea of using the version number as a filter. In my case, this is more correct as there is nothing wrong with the issue, it is defined we just know it's not time to start developing it.
BTW The URL link you gave was broken for me.
Are these "On Hold" Issues distinguished by a particular Status or e.g. a Label? In both cases, I think a Quick Filter in your Plan Board would be the handiest way to hide them when you don't intend to include them in your Sprints. When you want to review/work on the On Hold list, you can simply disable the Quick Filter to display them in the Backlog.
I agree with Christian, use labels!
Check out this blog! It describes a great solution to your issue!
I have implemented this and it work like a charm!
Thank you everyone for your prompt comments.
I guess I was trying to see if the consensus was a new 'status' or 'label' and of course the answer is 'depends on your specific requirements and preferences!' :-)
In our case, I think I will use the status / workflow approach. I've realised that we had already discussed add some new statuses to cover the 'authorisation' process of development work and I can in fact use those to differentiate work ready to be developed and items which are not.
In addtion to a status/label we use the fixVersion field to postpone an implementation.
The advantage for me as a product owner is to have a kind of a plan of the next implementations and to have them in a row not only in a long list.
With GH 6.1.6 versions can be filtered very smart and comfortable.
Hello, Community! My name is Gosia and I'm a Product Manager on Jira Server and Data Center here at Atlassian. Since 2002 when we launched our public issue tracker, jira.atlass...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG