Components of a Good Team Backlog

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 more directly based on Lean. In particular, systems-theory, the value of visibility of work to collaborate and the value of a standard workflow on which to make continuous improvement. Kanban’s perspetive on team boards can easily be adopted by Scrum teams and is usually always beneficial to do so.

The components of a good team backlog here are therefore based on Lean’s perspective of what works best.

Objectives of a Team Board

The objectives of a team board are:

  • help the team collaborate
  • let the team know when there is a problem with their work
  • let the team know of their agreements with other teams and vice versa
  • enable all levels of management understand the progresss they are making and the challenges they are having
  • set the groundwork for continual improvement

To best do this, it’s important for the team to create clarity on their;

  • workflow
  • agreements
  • work

We’ll discuss each of these below.


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 having the steps the work goes through be explicit. 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. This has the team figure out together what they should be doing. One example would be to have an agreement on whether to have a Definition of Ready and a Definition of Done. If this is agreed to by the team then people should follow it. Note, we’re not really following our board, but our 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 what we’ve made with our own team members and what we’ve made with those outside of the team. The workflow on the board (if made in the style of a Kanban board) will reflect our workflow. The board should also indicate any dependencies on other teams or those other teams have with the team owning the board.


Tracking work on the board involves three major dimensions:

  1. type of work
  2. status of work
  3. origination of work

Types of Work

Common types of work include:

  • value to customers
  • needed to improve our development environment
  • 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.