Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

¿How many boards are allowed?

Last post 02:06 pm September 24, 2014 by aldo daniel lavin
6 replies
12:10 pm September 8, 2014


Is it correct to have one board for each sprint? Or I have to use only one "Super-board"

I have posted this issue two times and I have no answer. If I'm doing this wrong I would like to somebody to tell me so.

Thanks in advance.

03:16 am September 9, 2014

I am not sure if I understand your question.
I guess you mean the SCRUM board, a tool that many teams use to represent their Sprint Backlog.
Product Backlog Items and tasks for getting them done are often represented as sticky notes on this board.
In this case you have one board, but the content changes continuously as more is learnt. Especially in the Sprint Planning the Dev team will pull some new content to the board.
What do you mean with "Super-board"?

01:17 pm September 9, 2014

Thanks for answer. I mean as super-board to only one board, because I have been using one board (digital), for each sprint so I can have the history for each. If I ony use one, where do I put all User Histories finished? Do I have to record them? Thats why I use several boards to mantain all the UH.

Thanks in advance.

02:45 am September 10, 2014

Ah OK.
So the question is: What value does the history have?
Remember we talk about software development and not archeology.
If you don't find a good answer, you don't have to record them.

10:12 am September 10, 2014

Hi aldolavin,

I'd recommend to use one Product Backlog on each Product and one Sprint Backlog for each Sprint - and to back up them frequently (if your "Boards" are digital, this should be no effort).
In this case
- you can track the complete history at any time you want
- you have the Product Backlog as "Super-Board" with several much more detailed Sprint Backlogs arising from the Product Backlog as "Normal Board".

I guess, history has the following value:
You can easily look up how things really were, if
- there are legal issues with a customer later on
- you have to develop similar requirements or increments on the same or maybe another product later on
- the Scrum Master wants to track process improvements (e.g. for further promoting Scrum).
If to you none of this adds value and you can't come up with other value-adding suggestions, I fully adopt to Ludwig's view.


12:45 pm September 14, 2014

> you have the Product Backlog as "Super-Board"...

That's a sensible approach, although we should also include the features of the Sprint Increment.


- A Development Team should be in the business of delivering potentially releasable increments of functionality. Their notion of inventory should therefore be the current Sprint Backlog and unreleased Work in Progress. They have no duty to track any other inventory.
- The Product Owner is accountable for product capability. That capability is expressed in terms of the Product Backlog (undelivered inventory, i.e. unimplemented capability) and the Increment, which is the delivered inventory and includes all previous increments and their capabilities.

02:06 pm September 24, 2014

Thanks for the answers... now is more clearly. I will use only one product backlog

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.