¿How many boards are allowed?

Hi,
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"?

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.

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.

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.

Regards,
AnotherDotCom.

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

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

Explanation:

- 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.

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