nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can one board show certain issue types on one view and others on another and remove them from WIP?

Amanda Ross

We currently have a kanban board and use quick filters. I have the query for our board to include all issue types, but not all issue types should be included in the wip. I'm trying to find a way to show some issue types on our board, but be able to filter out others so they only show in certain views. The ones I'm wanting to filter out, I want to show in a separate view (all within the same board and query) BUT those separate issue types should not count in our WIP limit. Quick filters doesn't solve this as they show the WIP regardless of which quick filter you're looking at. Would it be a sub-board? Sub-filter? I've never used either and don't know how to build one out? We could have two separate boards but....that's not ideal.

Accepted answers

John Funk

Hi Amanda - Welcome to the Atlassian Community!

You probably need another board to show the other issue types. There's not really a concept of a sub-board - it's just another board.

Most tools that measure WIP, Time In Status, Lead Time, etc. are going to use the board. So if certain issue types shouldn't be measured, then they should be on a different board in my opinion.

A sub-filter is not going to work, because it is just an extension of the main filter.

Nic Brough -Adaptavist-

There's no such thing as a "sub-board", and quick filters are "sub-filters".

You can't do this. A board is there to show you the work. It's going to count all the work on the board as wip because that's what they are.

If you don't want to see a certain issue type as work, that's fine, but you'll need to exclude it from the board, as the board will always see it as such. (Maybe add clause 'and issuetype not in (x, z, z)' and then have a second board that does include them)

Bill Sheboy

Hi @Amanda Ross

I agree with John and Nic about methods of separating out the issues... But I have a question: what problem are you trying to solve?

You say there are issues on the board that you want to remove, as they are not WIP; what are they and what do they represent? Why would they be on the board if they are not work?

If they are just a different type of work, aren't they still WIP? If they are other indicators, such as progress milestones, maybe they could be represented without issues.

Best regards,

Bill

Mark Slater_f9k1tr

Thanks to all. I think we have a plan.

All comments

John Funk

Hi Amanda - Welcome to the Atlassian Community!

You probably need another board to show the other issue types. There's not really a concept of a sub-board - it's just another board.

Most tools that measure WIP, Time In Status, Lead Time, etc. are going to use the board. So if certain issue types shouldn't be measured, then they should be on a different board in my opinion.

A sub-filter is not going to work, because it is just an extension of the main filter.

Nic Brough -Adaptavist-

There's no such thing as a "sub-board", and quick filters are "sub-filters".

You can't do this. A board is there to show you the work. It's going to count all the work on the board as wip because that's what they are.

Bill Sheboy

Hi @Amanda Ross

I agree with John and Nic about methods of separating out the issues... But I have a question: what problem are you trying to solve?

You say there are issues on the board that you want to remove, as they are not WIP; what are they and what do they represent? Why would they be on the board if they are not work?

If they are just a different type of work, aren't they still WIP? If they are other indicators, such as progress milestones, maybe they could be represented without issues.

Best regards,

Bill

Amanda Ross

Thanks Nic. That may be the what we end up doing. I got the idea of sub-boards from another thread https://community.atlassian.com/t5/Jira-Software-questions/How-can-I-create-a-Kanban-sub-filter-that-shows-all-issues/qaq-p/1126606. This person talks about using sub-boards. I thought maybe this was a function of Jira and I just hadn't seen it before.

Amanda Ross

Thanks for the reply. We may indeed need to keep two boards.

Mark Slater_f9k1tr

Bill,

I can answer this for Amanda. Essentially, our development organization has recently started the design to implement JIRA Align for our product/portfolio management activities. While Amanda's team is not a development organization itself (and therefore will not have Align licenses), we like a lot of the Product Management concepts Align enables, and I think they apply to our operations team.

The goal we are trying to achieve is that I, as the "product manager", need a view in which Epics (large, multi-quarter projects), Features (quarterly deliverables broken down from Epics), Stories (decomposed from Features), and defects can be prioritized against each other in a "product backlog" view. Then, the "development team" needs a Kanban view in which they pull in the sprint ready stories and defects based on our priority and estimations. We don't think we want the team including the Features or Epics in their board as they're really working on the burn down of the stories/defects (and also we don't want those Features/Epics affecting our WIP). From what I've seen/heard so far, if I want them included in the backlog PM view, they need to be included in the team's Kanban board query as well.

So long story short is we're trying to figure out the best way to create this Product Management backlog and a tracking board while also creating a more focused team-based board for the decomposed work that is committed to each sprint. Align seems to handle this use case nicely with the integration/replication of issues and data, but I can't figure out a great way to do this w/o it. Hopefully it's obvious and we're just missing it.

Bill Sheboy

Thanks for the explanation, @Mark Slater . That helped me understand the issue.

When I need to have multi-level views of work, on a physical or tool-based board, using two (or more) boards seems to help. For something like JIRA, that meant:

One Kanban board with the epic workflow (discovery to delivery), and
Other boards, Scrum or Kanban, with the delivery team-level workflow (selected to production).

Mark Slater_f9k1tr

@William Sheboy , that makes sense I had anticipated that we'd need different boards. From what I've been demo'd thus far, it seems like Features/Epic issues are either included in both boards or are in neither. Both boards are based on the same project FWIW, which I didn't think would be an issue, but that's our underlying issue we're trying to address. Can we have a single project with a backlog view that includes everything, but then 1 kanban board for the dev team w/o the Features/Epics (and associated WIP impacts) and another product manager board tracking the macro deliverables.

Mark Slater_f9k1tr

Thanks to all. I think we have a plan.

John Funk

Can you post back here what you end up implementing for folks viewing this in the future? Thanks!

Mark Slater_f9k1tr

Absolutely. We are going to create two boards: One to prioritize and track the Epic/Feature items, and another "team" board to prioritize and track the decomposed user stories (that are generated from those product backlog items), as well as the bugs and other work items.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

kanban

work-in-progress