Hi all, in our sprints we sometimes see ourselves forced to cancel a story. We then would like to filter it, to reduce clutter during our dailies/refinements.
I've tried doing this using (some variants of): issuetype = story AND status != Cancelled
This filters the Cancelled stories, but for some reason also filters away all subtasks, de-cluttering our kanban board a bit too much as you might understand.
I found this semi-related question, but I can't seem to be able to apply the solution to my case: Solved: Quick Filters are hiding my sub-tasks (atlassian.com)
Anyone know why this happens and how I can solve it? Thanks in advance!
Welcome to the Atlassian Community!
Sub-tasks, by definition, are not Stories. So your "issuetype = story" is excluding them from the results.
Maybe try "issuetype in (subtaskissuetypes(), story) and status != Cancelled"?
Thanks, you're right, that excludes the subtasks from being found but I'm a bit dumbfounded on what JQL I SHOULD be using at that point :-)
The solution you provided doesn't filter out the subtasks, but also doesn't filter out the cancelled stories on our kanban board.
The cancelled status is a resolution state if I'm not mistaken so that shouldn't affect this right? (see screenshot)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry, I went for explaining the logic over giving you the JQL that does what you need. But I'm not 100% clear on that, so I'm not sure what to give you.
Could you explain what you're trying to do with this quick filter - is it "hide all the issues of type "story" or "sub-task" on the board that are in status "cancelled"?"
(And as an aside, have you got "done" and "cancelled" mapped into the last column on the board? That will make your sprint reporting work properly)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your effort, much appreciated!
Our Active sprint kanban board is quite simple, we have 3 columns (To Do, In Progress, and Done). I checked our Columns configuration and saw that we had Cancelled under Unmapped statussen - I dragged it to the Done status column now, as per your suggestion ✅.
We have swimlanes based on stories, so sub-tasks are grouped under their parent issue.
We'd like to be able to filter out stories with the Cancelled status (and their sub-tasks), while "keeping" the other stories visible. Any further tips? (I can't overstate my lack of JQL knowledge..)
Thanks again
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, that's great, but it leads you to a bit of a two-part problem.
>We'd like to be able to filter out stories with the Cancelled status (and their sub-tasks), while "keeping" the other stories visible.
The first half is a doddle. "Filter out cancelled" - create a quickfilter for "Status != Cancelled". Job done.
The hard part is "(and their sub-tasks)".
A lot of us start by looking at exactly that definition. The instinct is to reach for a filter that says exactly that "Issues that are cancelled, and all their sub-tasks".
But that's actually damn hard to do in Jira, because it's not actually that useful!
Take a step back and look at what "cancelled" really means to the issue: "We're not going to do it; No, we ain't going to take it; We're not going to do it anymore".
Then look at what a sub-task is - it's a fragment of the issue. It makes no sense to have an issue that is done/ended/cancelled, but parts of it are not in a similar state. If you're not going to do anything about issue X, can it really have bits in it that you are going to do? No.
So, instead of looking at filtering, look at process. It's quite simple - if you say "we're done with this issue", then the process should automatically say "we're done with all the parts of this issue".
TLDR: Script or automate "when we cancel an issue, move all its sub-tasks to cancelled too" (Or any status in the "done" column that says this team is not going to do anything more with it)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah I see, that explains. We're missing that bit of automation. I'll be looking into that for now then. Thanks so far :-)
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.