Scrum Project or Kanban Project with Scrum and Kanban boards

[David Leal]

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

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

Configuration 2:

1. Project Type: Kanban
2. 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

[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]

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)

[David Leal]

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,

[Nic Brough -Adaptavist-]

I am not sure how else to explain it - projects contain issues, boards are a view of a selection.

Again, the project type is just a template, but it really doesn't matter because you can change it later. 

But as you're trying to do sprints, you will find it a lot easier to start with a Scrum project, rather than have to go in and add all the sprint artefacts you're going to need to add to a  Kanban project.

In my examples, I used projects A-E as a simple case.

Your choice of component is going to make a right mess though.  If an issue has two or more components on it, then two teams are going to see it.  The issue will move through other people's boards without that team working on it.

I strongly recommend using a field that is a single-select for the team discriminator.

[Kelly Arrey]

What @Nic Brough -Adaptavist- said - use a single-select field to chose which board a given ticket will show up on.

In the days before Advanced Roadmaps, when there was no "Team" field in Jira, we created a single-select field for the Dev Team, and mapped the Dev Team values to Jira groups of developers. This makes it trivially simple to write a filter for each team's board, and has worked very well for us.  We tried migrating to the Advanced Roadmaps Team field recently and ran into a few rather bizarre and arbitrary limitations (e.g., this one, this one). We quickly reverted to our custom field and haven't looked back.

[David Leal]

Thanks @Kelly Arrey and @Nic Brough -Adaptavist- I got the idea, and I had it in mind, on my project design, but I don't think the Team field, allows multiple values, where as components allows it. It seems to be a mess at first, but not really, because I mentioned we are implementing SAFe, so we can have epics (emulating SAFe Features) than. can be implemented by several teams. We can have the following scenario:

• Epic A, components: A,B
  • Story1, component: A
  • Story2, component: B

so two teams A, B contribute to the epic on different stories and each team board will see only the specific portion of the epic that relates to each team. If I do by team field, If I am not mistaken, but maybe I am wrong, you can not assign multiple teams to the epic, so we cannot achieve the behavior we want. Other than that team field for isolated work is a good solution. Thanks again!

[Nic Brough -Adaptavist-]

That makes sense, but actually, I wouldn't put the "components" on the Epics at all (not as the same field as the Stories are doing).

I would

• Define a single-select field to identify your "component", and use it on all issues at the story level (it could indeed be the Team instead of "component".  I'm using "component" to distinguish your data from the system "component/s" field, which is a multi-select)
• Define a multi-select field for Epic-component, with the same list of components in your single-select
• Create an automation that says "when component is added or changed at a Story level, check if the Epic has it, check if the other stories beneath it have it, and add/remove it from the Epic-component as required"

This will avoid all the complexities of having to ask your people to not put multiple "components" and coping when they  do (because they will), and stops the Epic from spamming itself (and in some cases, its stories) across many boards.

[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]

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.

[Kelly Arrey]

Jira Kanban boards have supported backlogs for several years.