Why do issues in Backlog-Statuses appear on the Kanban board, depending on their subtasks?

[Robert Kalweit]

Here's my problem:
The team has worked on some issues during our Kanban. Now we have decided that some Parent-issues have to move back to the backlog. While before I have never experienced that problem, now this seems to break our entire overview:
Our Kanban-board shows swimlanes by User Story and now it still shows issues in statuses

• Open
• Refinement

despite those statuses being mapped to the backlog. The swimlanes contain sub-tasks ranging from "ToDo", "In Progress".
The same problem happens with (I know it's an anti-pattern) User Stories in Backlog-statuses that contain 3 done sub-tasks, 0 sub-tasks in other statuses.

[Esther Strom · Accepted solution]

Hi, @Robert Kalweit

If a board is swimlaned by story and some of a story's subtasks are in statuses that are not mapped to the backlog, the stories will appear on the main kanban board because the stories are the "category headers" for the subtasks in the swimlane.

In this example, you can see that I have a story in To Do status (mapped to the Backlog view) which has three subtasks. One is Done, so it no longer shows on the board at all (because of the Kanban subfilter which hides completed tickets.) The other two are In Progress, which is mapped to the In Progress column on the kanban board. Because the subtasks are in a status that is mapped to the kanban board, their parent story shows as the swimlane header, even though the story is in a status mapped to the backlog.

This is expected behavior; the only way to not show in progress subtasks when the parent is still in backlog is to set the subtask statuses back to whatever your backlog status is.

If this isn't the issue you're describing, can you please post screenshots to clarify?

[Robert Kalweit]

Hi Esther! Thank you so much.
What an elaborate and insightful answer in SO little time :)

You exactly got my issue and explained things well.
So I'm happy (about the quick resolution of the question) and sad (about the inability to change this behavior) at the same time.

I would have liked, if the team decides for some reason that some issues can't be moved forward at the time, at least I can declutter the board from their subtasks :( A behavior more similar to a Scrum Board (but without Sprints) would be nice.

Thanks again for the help!