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; } } }

Scrum Project or Kanban Project with Scrum and Kanban boards

David Leal_28ge8x

Considering that you can have a specific project type (Kanban or Scrum) and then multiple board regardless of the project configuration. What are really the main difference (advantages and disadvantages) from the following two configurations:

Configuration 1

Project Type: Scrum
Board A (Scrum), Board B (Scrum), Board C (Kanban)

Configuration 2:

Project Type: Kanban
Board A (Scrum), Board B (Scrum), Board C (Kanban)

We want to have everything in a single project and distinguish teams by components. The Board C correspond to Architectural Runway Team, that maybe fits better Kanban (I don't know what is the best practice around this). In both cases we want multi-sprint (parallel sprint) option enable, so we can have more than one active sprint at the same time. Per my understanding this configuration is at a project level not at a board level, correct?

Since we are not sprinting at project level, just at a team level. The only advantage I see for Configuration 1, is that you can have in the main project board, in a single view all the Active Sprints for both Scrum Board and also in the backlog you can see all the Sprints we have defined in both scrum boards.

Under Kanban project you can have a simplified view of the entire project, but not a global visibility to all the sprints of the project. You need to go to the specific Scrum board to visualize the information. Since we want to enable multi-sprint I don't know if this option is available for a Kanban project too (I am not JIra admin). if it is not possible, then it would be deal break.

Is there is anything else we would need to consider to make a decision on which scenario fits better?

We are looking for a best Jira project configuration, for our next PI, and we are evaluating the pros and cons of each configuration under a single Jira project. I don't think it is possible to convert the project type from Kanban to Scrum and viceversa once it was created, so the decision we are going to make should remain in the future. That is why I would like to evaluate the pros and cons of each configuration. Thanks

Accepted answers

All comments

Sabeena

Hi David,

A Kanban project doesn't allow to run sprints, therefore, there is no backlog feature in Kanban board.

Whereas, a Scrum project has all the necessary features as backlog and sprints and if you don't want to use them you can still just keep it simple and continue using like a Kanban board.

So, it would be better to setup the projects as Scrum as you can later use it as Kanban but can't do the opposite.

David Leal_28ge8x

Thanks @Sabeena for your prompt response, but I am not following you. You can have a Kanban project and then define a Scrum board and have sprints, so you can run sprints within a Scrum board, from a Kanban project. That should not be a reason for not to chose a Kanban project under the mentioned configuration, or maybe I misunderstood you.

Nic Brough -Adaptavist-

TLDR: You are aiming to do Scrum, so I would create Scrum projects

The project "type" in these cases is actually the type of the template, not the project.

Confusingly, there's three ways people use the word "type" when talking about projects:

Whether it is team-managed or company-managed project
Whether it is a Software, Service Management, Work Management or Product Discovery project
The template used to create it (scrum, kanban, bug tracking, process control, HR service management, etc)

But. The template is that it only applies at creation time. It defines the setup of an empty project, with some defaults by the type. Once created, it's irrelevant, you can change whatever you want.

If, for example, you create a Scrum project, you'll find you get a project with a certain set of issue types, Story points enabled, and a Scrum board created automatically. With Kanban, you'll get a Kanban board and no estimations. But you can always add a different type of board (in a company managed project), add the estimate fields to it and so on, effectively converting it to what a Scrum template would have done. And by removing estimates and disabling sprints, converting a Scrum project to a Kanban one.

>"Since we want to enable multi-sprint I don't know if this option is available for a Kanban project too"

Kanban does not have sprints, nor estimates, so no, you can't use a Kanban board to do sprints.

David Leal_28ge8x

Thanks for your response @Nic Brough -Adaptavist- very explanatory. So when we select a type of project what we are actually selecting is a specific project template.

About my following statement:

Since we want to enable multi-sprint I don't know if this option is available for a Kanban project too

Yes, Kanban type of project doesn't have Sprint nor estimation, true, but we can add Scrum Boards for example and to have Sprints and also to define estimations. Your response refers to Kanban board, which is not the scenario (I don't pretend to have Sprints in a Kanban board). My question is about what configuration should I use considering in both Configuration 1, 2 hybrid boards (2 Scrums and 1-Kanban), but I don't know what would be the best approach maybe I am missing something. If parallel sprint is something can be configured at Jira instance level, then that is not a factor to decide. Then what other factors I should take into consideration in my decision?

Let me explain in more details what I have on each project type option under each configuration:

If my project is Scrum (Configuration 1), then:

The main board (the one created with the project) is a Scrum board. I can select in the Sprint board the active sprints (one of both), but I cannot see the Work in Progress (WIP) from the Kanban team, so I loose this information from the overall view
In the Backlog view (for the main board), I see everything that is pending, i.e. future sprints defined in the Scrum boards, and work in TODO from all boards.

If my project is Kanban (Configuration 2), then:

The main board now is Kanban, therefore there is no Sprint information, it shows the WIP issues on the column statuses of the Kanban board settings. I can see all WIP. So I have an overall picture of my entire project.
The backlog view (for the main board), doesn't show future sprint, but rather the work pending: TODO

so on each case, I can visualize different information. I would say if parallel Sprint is enabled at Jira instance level, then having a Kanban project, probably for the main view (Kanban board and backlog) you have a better picture of the WIP and future work (in the backlog). I don't see future sprints, but I have this information on each backlog of team A,B, so not a deal break, so this approach in my opinion is more generic.

So I would take this decision (Configuration 2), but I am not sure If I am missing something else that make me reconsider this approach.

Thanks in advance,

Nic Brough -Adaptavist-

When using multiple boards, there are some important things to bear in mind.

A board is effectively the same thing as a "team" - it's a team's view of what they are all doing. Jira Align actually goes as far as not to have any distinction between them - if you can work on issues shown on a particular board, then you are part of that team.

A board is a view of a selection of issues, it's not a container. Issues can appear on many boards (which we need to do multi-board setups), but when you amend an issue in one board, you are amending the issue, so it affects what people see when using other boards it appears on

Scrum sprints are generated within and remain closely tied to a board. Their board is the one that is supposed to be using them. But because issues can appear on other boards, you may find people from the "wrong" team amending them. It is very easy to get confused. Especially if you have parallel sprints enabled!

A backlog and a board are not really separate entities - a backlog is an optional adjunct to a board. They work for the same team, from the same filter.

So, with all of that brain-dumped...

One simple recommendation - for all your Scrum teams,

Set them up with a single-team Scrum board
Try not to include issues in their board if they are never going to work on it
Make that the place they at least plan in, when they're building their sprints, refining the backlog, and where they start with all their reporting
Similar advice goes to a Kanban team - identify a "main" working board focussed on the team

And then...

Knock yourself out with other Kanban boards! Your teams can work from their own "main" boards, Scrum or Kanban, and then you can create an overview Kanban to do what you need to do, diving into have a look at the team's Scrum boards if you need to.

The one thing that doesn't work well here is having more than one Scrum board for the same sets of issues.

One simple example of working well with multiple boards is to use board filters like:

Team 1, scrum, project in (A, B, C) or (Project in (A, B, C, D, E) and label = team-1)
Team 2, kanban,project in (B, C, D) or (Project in (A, B, C, D, E) and label = team-2)
Team 3, scrum, project in (E) or (Project in (A, B, C, D, E) and label = team-3)
Overview team (you!), kanban, Project in (A, B, C, D, E)

Kelly Arrey

Jira Kanban boards have supported backlogs for several years.

David Leal_28ge8x

Thanks for your detail response @Nic Brough -Adaptavist- Just some comments:

A board is a view of a selection of issues, it's not a container

What do you mean by container on this context? It is clear to me that is a selection of issues, because it is based in a filter.

I am incline to use KANBAN project, i.e. my Configuration 2, based on your comments and on my research it seems to be the best approach. Even though as you mention it is just a template. My boards are discriminated by component, so I won't expect to have a mix of issues in more than one board. Except for Shared Epics (SAFe Features emulated by Jira Epics), where a portion of the epic will be implemented by one team and another portion by another team, but at story level the BAs will assign just one component.

I don't follow your example for multiple boards, you are using as filter a query that include more than one project: A,B,C,D, E. In my case I have a single project, but multiple board within the same project.

In my approach the filter for Board X (were X can represent A, B, C components on each case) is as follow:

PROJECT IN (Y) and COMPONENT in (X) ORDER BY RANK ASC

and for the main board (overall view):

PROJECT IN (Y) ORDER BY RANK ASC

Thanks,

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud