Greetings,
We are using 'fix version' in a non standard way. JIRA is opinionated and believes that you should plan up front your release identifier, add it to 'fix version', address the issue and mark it with such version.
This is certainly good enough for waterfall and agile (scrum) delivery but it is not sufficient for lean (kanban) continuous delivery. It is impossible to forsee the future in such environment because basically issues get resolved and pushed to production as they are addressed.
What we did was to use the JIRA API to add our BitBucket tags as 'fix version' items in JIRA, that way developers can always pick the version that is carrying their solutions. This works fine so far.
The problem is that marking the 'fix version' as 'released' makes the ticket holding such version dissappear from the Kanban Board which is incorrect because the ticket might be in a stage like dev-done or uat-in-progress and definitely we want to be able to see such ticket in the Kanban Board.
Most likely this not an issue for the majority out there because again JIRA is opinionated and considers "released" to be a synonym of "deployed". In a continuous delivery environment you are constantly releasing and testing, however issue resolutions get deployed only when quality is good enough.
I think JIRA should make the Kanban Board configurable through a filter that would allow some users to exclude the "released" fix versions while it would allow others to leave them there. Thoughts?
If this makes sense I would create an issue for future resolution. For now we just know that we cannot mark our 'fix version' as 'released'.
Cheers,
- Nestor
The recent versions of JIRA have a "sub-filter" on Kanban boards. I found this in ours:
fixVersion in unreleasedVersions() OR fixVersion is EMPTY
Deleting that from the sub-filter (under "Configure Board > General") fixed it for us.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Big thank you as well. This "feature" wasted an unnecessary amount of my time trying to resolve. You're a great help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You're likely seeing this behavior because kanban boards default their queries to include "and fixVersion in unreleasedVersions()". Remove that part of your query.
We replace with "and status != Done or (status=Done and status changed < -3d)" to have the issues automatically drop off the board after they are in our final status (Done) for more than 3 days.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks. Fixed. I removed the restriction from the Kanban board sub-filter and it worked as expected.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Randy's second Sub-filter suggestion is a good one to keep that Done column from getting excessively long on Kanban boards. I prefer two weeks ("-14d") but customize it for how much you want to see based on your team(s).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.