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.



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.

  • Thank you for your feedback, was very helpful and I learned a lot from it! – Maxim Geerinck Nov 29 '14 at 22:40

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.

  • 2
    Thank you for this, it's very helpful to see a real-life example. – Maxim Geerinck Dec 1 '14 at 9:17
  • I'm looking into managing a small web team with several permanently ongoing projects and your answer has been very helpfull. Thank you – LNubiola Feb 4 '17 at 10:14

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.

  • This +10. I find myself having the same argument about this over and over. If Scrum is not adaptable then it is essentially just another prescriptive technique. Ken Schwaber said he hated writing the books because they were so far removed from the fluid conversation he was trying to have. If you cannot adapt Scrum then neither it, nor the individual are Agile. – Venture2099 Dec 4 '14 at 7:51

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.

  • 1
    In scrum you use 1 board per project. The story board, which is similar to a Kanban board, (there is no such thing as a scrum board) is simply a visual tool for tracking stories throughout a Sprint. Projects are delivered over Sprints, and stories/tasks are sub-components of a project. Teams do the delivery. While usually there is a 1:1 between project and team, it is possible to have 1 team delivering on 2+ different projects with different cadences, hence more than 1 story board. – WBW Dec 1 '14 at 23:15
  • No, you don't. One team, one backlog, and if you chose to visualize it, you use one board. – Andrew Clear Dec 2 '14 at 4:51
  • 1
    That's a purist view of Scrum. In Agile-scrum its quite possible to have 1 team across two different backlogs with more than 1 product owner. Its probably ill-advised in most situations, but if it benefits an organization more than the 1:1 paradigm in some circumstances why not allow it? – WBW Dec 2 '14 at 20:59
  • 1
    I'd also throw in that swimlanes used on a single story board has a similar affect to having 2 different story boards. More importantly, what is the problem that you are trying to solve with using 1 or more story boards? – WBW Dec 2 '14 at 21:02
  • See CodeGnome's answer, he gave the long version. – Andrew Clear Dec 3 '14 at 1:49

Your Answer

