Can we use only one Scrum board for a team with multiple projects?

Question

I am doing research for school. My research is covering how we could have one Scrum board for one team that works on multiple projects simultaneously.

Scrum methodology is not just for working on one project. Scrum tells us what kind of work we have to complete and how we are going to complete it, and in what timespan.

A lot of companies and articles say that we can have one Scrum board where we include different tasks for different projects. Most projects cover the same bases: they have a UI, they have a domain model, etc.

I was wondering how companies manage their single Scrum board for different projects, what the advantages/disadvantages are, and if we should have one board or multiple boards.

Answer 1

TL;DR

My research is covering on how we could have 1 SCRUM board for 1 Team that works on multiple projects simultaneously. SCRUM methodology is not just for working on 1 project, it tells us what kind of work we have to complete and how we are going to complete it (and in what timespan). [Sic transit throughout.]

Working on multiple projects simultaneously is neither agile nor Scrum. Scrum is not prescriptive, and doesn't tell you how to do your work or how to implement anything not expressly mandated by the framework.

Whatever you're doing, it isn't Scrum. It doesn't even sound very agile. Your research project is off to a very bad start if it considers these anti-patterns to be part of the canonical Scrum framework.

There's No Such Thing as a "Scrum Board"

A "Scrum board" is not a defined artifact in the Scrum methodology. However, many Scrum teams borrow the concept of a visual board from Kanban; this can provide a visual representation of the Sprint Backlog for the team during each Sprint.

However, neither the format of the Sprint Backlog nor the use of a Kanban-like story board to visualize user stories is mandated by the Scrum framework. Scrum simply mandates the existence of a Sprint Backlog for each Sprint, and leaves the specific details of the implementation up to the Scrum Team.

One Team, One Product Backlog

A Scrum Team works from one, and only one, Product Backlog. Multiple projects can feed into the Product Backlog, but it is the job of the Product Owner to sequence all inputs into a single, prioritized Product Backlog for the Scrum Team.

If the Scrum Team uses a kanban to represent its Sprint Backlog, it must use a single board. Since a Scrum Team can only participate in one Sprint at a time, the idea of having multiple Sprint Backlogs in any form (whether spreadsheet or story board) is simply not acceptable within the official framework.

You Can Do Almost Anything You Want, But It Won't Be Scrum

You can, of course, do almost anything you want and call it a project management process. You can have one team work on 57 projects at a time. You can fill your walls up with dozens of story boards. You can even write user stories on paperweights stored inside Hello Kitty lunchboxes if you genuinely feel it adds value to your process.

The one thing you can't do, though, is call what you're doing "Scrum." Scrum is a well-defined framework, with the framework specifics clearly spelled out in the Scrum Guide. If it isn't documented in the Scrum Guide, it isn't officially part of the Scrum framework.

Many experienced Scrum teams add or borrow practices that are not incompatible with the Scrum framework, so long as those practices adhere to the Agile Manifesto or its Twelve Principles. However, principles aren't practices, so you'd be hard-pressed to call Scrum anti-patterns agile practices even if they aren't actually prohibited by the framework.

Answer 2

Although I cannot fault CodeGnome's answer above, I feel like the question has not been fully answered and we circle back once again to the flexibility of the names Agile, Scrum, Kanban etc.

Maxim, you have several component parts to your problem which; all of which we face in our department.

• Multiple Project Requirements (Backlog)
• Project Backlogs merging into one (or several) unified backlogs
• Visualisation of current sprint tasks
• Forward sight of tasks occurring in future sprints

I recently attended a meeting where one of Jeff Sutherland's friends and original Scrum adopters reiterated that Scrum is adaptable and multiple backlogs may simply be a fact of life imposed by management. It does not magically stop being Scrum.

Our process works with the following ceremonies and artifacts Maxim.

1. Product Owner for Sales and Marketing generates his Product Backlog (14 Projects)
2. Product Owner for Finance generates his backlog (11 Projects)
3. Product Owner for Commerce generates his backlog (60 projects prioritised to 12)
4. All individuals attend a quarterly planning ceremony where we generate the Kanban Baord for the year at Portfolio/Programme Level
5. 12 x Monthly Sprints
6. Sprint Planning takes place monthly merging 3 Product Backlogs into a single Sprint Backlog according to the prioritisation of the business
7. Sprint Kanban Board produced for User Story and Task Level items

The two Kanban Boards are colour coded showing the dependencies between both so that each developer can see at a glance where the User Story (also colour coded) fits into the wider picture.

I hope this helps.

Answer 3

If you stick to a strict interpretation of Scrum, 1 story board = 1 team = 1 project.

Could you use multiple story boards? Sure, but purists would probably argue you're not doing Scrum anymore.

Are you doing Agile-Scrum? Yes, possibly...

If the solution you choose (one or many story boards) is desired by the team(s) and improves their ability to deliver on commitments, then I'd argue you are still doing Agile-Scrum.

Scrum is a proscribed set of tools/processes for delivering software.

Agile is more focused on results and is a school of thought; it does not proscribe the specific tools/processes to get there.

At some point Agile-Scrum becomes a contradiction; when Scrum limits the capabilities of the team.

Answer 4

The short answer: in Scrum you use 1 board per team. The Scrum board is simply a visual tool for tracking tasks during a Sprint. It is project/component agnostic.

Answer 5

To address your scenario, where you need a dashboard gadget that displays tasks specific to each team on their Kanban boards, you can follow these steps:

Create Filters for Each Team:

1. Use JQL (Jira Query Language) to create specific filters for each team. These filters will target the tasks assigned to each team based on their criteria, such as assignees, labels, or components.
2. Example JQL for a team filter:

java project = "YourProject" AND component = "TeamA" AND status != Done

Set Up Kanban Boards:

1. Ensure each team has its own Kanban board configured. This can be done by creating separate boards for each team if they do not already exist.
2. Go to Boards > Create Board, select Create a Kanban board, and then choose From an existing project or From an existing filter.
3. Associate the board with the relevant filter you created for the team.

Configure the Boards:

1. Configure each board to ensure that it displays tasks as per the team's workflow.
2. Navigate to Board settings > General and select the saved filter for that board.

Dashboard Gadget Configuration:

1. Go to your Jira dashboard and click Add gadget.
2. Add the Filter Results gadget or Kanban Board gadget to your dashboard.
3. Configure the gadget by selecting the filter you created for the respective team.
4. Customize the columns, sorting, and fields displayed as needed.

Automate and Maintain:

1. Regularly update the filters and boards as team structures or task assignments change.
2. Consider using automation rules in Jira to keep the filters and boards aligned with changes in task assignments dynamically.