Disciplined Agile

Practice: Components of a Good Team Board

Why to Do This Practice

Scrum and kanban originators have different mindsets about the visibility of work. Scrum is described as an empirical process without there being a consistent flow. This is why it uses tasks on stories because then each story can have a unique workflow. Kanban is based on lean principles, placing a high value on making work visible to promote collaboration and recognizing the value of a standard workflow to help with continuous improvement.

Kanban’s perspective on team boards can easily be adopted by scrum teams and is usually always beneficial to do so.

The objectives of a team board include:

  • Helping the team collaborate
  • Letting the team know when there is a problem with their work
  • Letting the team know of their agreements with other teams and vice versa
  • Enabling all levels of management understand the progress they are making and the challenges they are having
  • Setting the groundwork for continual improvement

Components of the Board

To best do this, it’s important for the team to create clarity about workflow, agreements, and the work to be done.

Explicit Workflow

The workflow of a team includes the steps the work goes through to go from ready (on the iteration backlog) to done (accepted by the product owner). There is an advantage of making explicit the steps the work goes through. In this case, “explicit” means “discussed and agreed to.” It doesn’t mean hard to change.

This explicit statement of work represents what the team believes is the best way to do their work as of the time it was last discussed. The team must figure out together what they should be doing. For example, they must agree on whether to have a definition of ready (DoR) and a definition of done (DoD). If this is agreed to by the team, then people should follow it.

Note, we’re not really following the board, but the board represents the best way we know how to do our work. If we’re not sure, or don’t want to have a standard, then that can be represented on the board with a “do what you think is best” tag.


Agreements include agreements we have made with our own team members and agreements we have made with those outside of the team. The workflow on the board (if made in the style of a kanban board) will reflect the workflow. The board should also indicate any dependencies on other teams, or dependencies that other teams have with the team owning the board.


Tracking work on the board involves three major dimensions:

  • Type of work
  • Status of work
  • Origination of work

Types of Work

Common types of work include:

  • Value to customers
  • Work that is needed to improve our development environment 
    Work that is needed to do a story targeting customers
  • Maintenance
  • A spike
  • A story that has a required by date

Status of Work

Status of work is often indicated by the column it is in if one is doing a Kanban style board. If not, stories can be tagged to indicate certain actions have been taken. In any event, stories that are blocked need to be identified as such. How much work is completed should also be readily available.

Origination of Work

Teams are supposed to pull from their backlog. But it doesn’t always happen that way. New work gets inserted either by the product owner or by manager’s who use their rank to get things inserted – sometimes without anyone other than the developer knowing. While it is easy to say “just say no” it is often difficult for a developer to do so to management. Work originated outside of the normal team protocol can be designated as such so that we create visibility on it.