From an Agile perspective: Is it better to use one single board for an entire (large and diverse) team/project or multiple boards for different sub-teams that share the same workflow?
Background:
I run a support team where we take on: project work, investigation/tickets and bug fixes/code patches. We support multiple applications and service both internal and external customers.
We used to 3 boards:
One for the issue backlog where stakeholder could view and prioritise issues for us.
One for the investigation team
One for the developers.
All boards are part of the same project and share the same workflow and issue types and an issue would and would often move across all boards (if necessary) during its lifecycle.
- Backlog board: 150+ of items in the backlog board, but managed and maintained by multiple stakeholders managing their own issues.
- investigation board: Typically with 25 or so issues in priority order leaving scope for unplanned work each period. With items either go to "done" or "Dev queue" when required
- Dev prioritised list -> in progress -> done : Typically with 15 items in priority order
This worked quite well until a new manager took over and insisted that we work off one board as that "is the agile way". Now we have a board with 6 columns, multiple statuses within each column and around 200 items on a single board.
As you can imagine, this even with 25+ quick filters, this is virtually impossible to manage. and I'd like to go back to a system that worked well for us and stakeholders.
I can find anything, anywhere that suggests Agile/Kanban best practice is to put all issues on one board. But If anyone can point me towards any Kanban/Agile articles that might suggest one board is better or worse than multiple, I'd be most grateful.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.