My team just have moved to Kanban process using Jira. We pretty much configured everything (board, filters, fixversions, etc) and accomplished a few released already. Issues are disappearing from Kanban board once FixVersion is set and version is set as "released".
However we have some additional challenges and additional manual work involved, since it doesn't cover our process fully. The thing is that not absolutely every Jira issue is related to particular release/FixVersion (i.e. no code changes involved). There are tasks like:
All these tasks are done in the scope of same team, same workflow, same user/tech-stories (I'm not speaking about pure management-administrative tasks). Such tasks just not related to any specific version.
What is common practice to handle such tasks in Jira Kanban process? Leaving such tasks without FixVersion - issues won't disappear from the board. Setting "future" version is not always correct, because we don't know exactly when next version will be released, while task is already "done" and live. Setting "past" version is also not good, because it alters already communicated release. We are considering to end it by setting some "virtual" FixVersion value, but it also still looks for me like a dirty workaround..
Any other suggestions?
How are you? I hope you're having a nice Tuesday.
I understand that you would like to know what is the best practice to remove/handle the tasks that are not related to a release from your Kanban board once they are done. Is that correct?
I think you have two options here:
1 - Define a new virtual Version as you mentioned
This option will allow you to track the progress and velocity of these tasks since you will be able to access the reports related to the version.
2 - Configure your board filter to properly remove the task once it is moved to Done
This option will simply remove the issues from your board once they are finished. Also, there will be a limited number o reports to track the progress of these tasks. Let me know if you would like to proceed with this option and I can further help you with the filter query.
I particularly think that the first option would be the best one since it will give you more ways to track the task during their progress and once it is done.
Let me know if this information is useful. :)
Hi, thank you for the response! Yes, you got my goals right.
I was considering both your suggested options as well, and that's what I think..
1# - in this case I'm a bit afraid that we either will end with quite a lot of "small" releases, or with one "big" release used forever, which will be set on all such tasks (while tasks might be related to different components). Of course it's an option, but it's still - to set something, just to hide the task from the board.
2# - this seems even less suitable for us. Filter is not a problem, but sometimes we "close" tasks before they are released (i.e. we want to see them in board as "done", until they are released). Again, maybe some aspects of our workflow are wrong, but there are both historical reasons and other two-edged-sword kind arguments. One of this - is that in our workflow task is marked as "closed/done", when QA finishes testing and wants to move out the task from "his" column. It probably could be solved by adding one more status between "tested" and "done", but we don't really want to have 10+ columns in our board..
Thank you for ideas! I acknowledge that there is probably no silver bullet for this, and there is zero Jira fault in it, but I would be curious to hear some more opinions/practices. Somehow I feel it should be quite common challenge with Jira Kanban boards.
The Jira Software Cloud Team has been busy working on a simple, secure, and reliable way to integrate your build and deployment information from Jenkins with Jira Software Cloud. This means you don’t...
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