Handling a Project with a combination of Scrum and Kanban boards

[Vj]

Hi,

I have a scenario where part of the stories follow Sprint Cycles and the rest of the stories fit Kanban mode of execution. So, I have created both Scrum board and Kanban boards. I have enabled Epics, Stories, Bugs, Tasks and Sub-Tasks. I have separate the stories in the fashion that if a specific Epic is the parent, the story should appear on Kanban board, otherwise on the Scrum board. While this works well for the Stories, I am looking for some support to understand how we manage Bugs, Tasks and Sub-Tasks to keep appearing on the Kanban board. Can I handle this through JQL or any automation?

[Jack Brickey]

Hi @Vj ,

there are a number of approaches here. The Key concept understand is that boards are defined by filters. These filters are created using various issue field attributes. So if you want to containerize project activities so that you can manage them differently, such as kanban and scrum, then we need to leverage some field within the issue. One method of doing this, which might work well here, is to use the Components field. Other possible solutions include: labels, custom field, or issue types.

As an example, let's say you decide to use components and these components  break down as follows:

• platform, backend, UI >> Scrum
• operations, PM, sales >> Kanban

then you would create boards from filters like this:

• scrum - project = abc and components in (platform, backend, UI)
• kanban - project = abc and components in (operations, PM, sales)

finally, one thing about components that I don't like in this specific situation is that you can have multiple components for a specific issue or none at all. What this means is that you can end up with a mix of components that would cross your boards resulting in the issue appearing on both boards. Also, if the components field is empty, where does it go? That would need to be defined. as an alternative, consider a custom field that is required at the time the issue was created. This custom field would be a single-select drop-down, and the user would have to select a single value.

[Vj]

Thanks for sharing your thoughts around the approach, @Jack Brickey. We are discussing on the approach to take. Was exploring options avoiding more fields to be defined. Considering Labels to see if that can be a good candidate towards achieving this demarcation.

[Yuri Lapin _Release Management_]

Hi @Vj

I hope this message finds you well.

If you are up to Partner Apps would suggest to try our Advanced Kanban and Agile Boards. We allow to merge Scrum and Kanban teams in a single view. So, in case you share more or less same workflows for your Scrum and Kanban teams you can:

• Create / Use existing sprints as swimlanes with all the Sprint Management from swimlane (create sprint, start, complete, etc ..)
• Have Other (or name it the way you like) for Kanban
• It's also collapsible/extendable to let teams to focus on their thing (their swimlane)
• Plus loads of usability features and product features to make Scrum better with some advanced Kanban practices. You might also want to watch a Webinar we did with Kanban University on that topic - https://www.youtube.com/watch?v=sivVyereSNE

Hope this helps.

Cheers,

Yuri.

[Vj]

Thanks Yuri. Going through the link you shared to understand better.

[Mary from Planyway]

Hi @Vj 

It's Mary from Planyway for Jira

Managing a hybrid project setup in JIRA with both Scrum and Kanban boards can be quite effective for handling different types of work within the same project. Your approach to separating stories based on the parent Epic is a good start. For managing Bugs, Tasks, and Sub-Tasks in a way that ensures they appear on the Kanban board, while still maintaining their visibility and organization within the Scrum framework when necessary, you can indeed leverage JIRA Query Language (JQL) and automation rules. Here’s how you can approach this:

Using JQL

JQL can be used to filter issues for your boards based on specific criteria. For your Kanban board, you can create filters that include Bugs, Tasks, and Sub-Tasks associated with Epics or stories that are meant to be managed in a Kanban fashion. Here's a basic example of how you might set up a JQL query for the Kanban board:

project = "YourProjectKey" AND (issuetype in (Bug, Task, Sub-Task) AND "Epic Link" = "YourEpicKey") OR (issuetype = Story AND "Epic Link" = "YourEpicKey")

This query ensures that only Bugs, Tasks, and Sub-Tasks linked to a specific Epic (alongside stories linked to the same Epic) appear on your Kanban board. You would replace "YourProjectKey" and "YourEpicKey" with the actual project and Epic keys you are working with.

Using Automation

JIRA's automation features can also help in managing where issues appear and how they are handled within your hybrid setup:

1. Automatically Assigning Issues to Epics: You can set up a rule to automatically assign Bugs, Tasks, and Sub-Tasks to a specific Epic based on certain criteria. This can help in ensuring that these issue types are automatically categorized for Kanban or Scrum boards as needed.

2. Moving Issues Between Boards: Although automation cannot directly move issues between boards (since boards are just views based on filters), you can automate the transition of issues to specific statuses that are then reflected in the board filters. For example, you can have a rule that when a Bug is marked as a certain type or priority, it is automatically transitioned to a status that is included in the Kanban board's filter.

3. Syncing Parent and Sub-Task Statuses: For maintaining consistency, you might want automation rules that sync the statuses of Sub-Tasks with their parent issues or vice versa. This ensures that when a parent Story moves forward in the workflow, its Sub-Tasks are not left behind in the Kanban board without updates.

When setting up these automations, go to Project settings > Automation (you might need admin rights), and then create new rules based on the triggers (like issue creation or updates), conditions (such as issue type or links), and actions (like transitioning statuses or updating fields) that suit your workflow needs.