Your Scrum or Kanban Board — Best Practices

Controlled and balanced flow of work-in-progress is one of the key success-factors for high productivity and successful delivery. Introduced as part of lean manufacturing the underlying concepts and principles have now become an Continuous Delivery mindset. This post does not discuss agile flavours such as Scrum or Kanban per-se, but specifically best practices for the use of so-called Scrum and Kanban Boards as one of their key tools to manage workflow.

Why

The purpose of Work-Item Boards, whether for Scrum or Kanban, is to visualise scope and status/stage of currently relevant work items and thus support the management of work in progress and delivery overall. More specifically they are a tracking and communication tool (‘what’s going on’, ‘who’s doing what’), provide insight into potential issues (bottlenecks) and risks (starvation, pile-ups, item size) and are a great source of motivation (ownership and delivery progress, ‘We are done with that :)’).

Goals

We use such boards (and related practices) to:

• Optimise flow of work: Ideally we want an even flow (balanced number of items in each stage and minimal/no waiting times between stages) of minimal batch sizes (limited number of small stories)
• Ensure clear work priorities
• Ensure clear work item ownership
• Provide early insight into potential issues (bottlenecks, blockers, work item starvation, excessive work item size, etc)
• Use the board to facilitate, not to micromanage!

What good looks like

1. Have a physical board in addition to your digital one
2. Keep the number of columns to a minimum
3. Only place tickets that are relevant i.e. actively worked on in the current work cycle; but represent all that is ongoing. But keep it high level, in most cases there is no need to track all tasks / task level. Start with Stories.
4. Succinctly and clearly name tickets and link them back to the backlog item
5. Define “Definitions of Ready” and “Definition of Done” as conditions that must be met when moving work items between stages and ensure they always being met
6. Optimise for an even flow of work, i.e. balance/limit the number of items in each column based on team capacity.
   Avoid starvation: Keep the team well-fed with items but not overloaded. Act on columns with excessive items, especially if they start piling up mid-flow: investigate and resolve the bottleneck or consider halting work in previous stages until the bottleneck is resolved.
7. Reject any inappropriate work items (too large, not of good quality)
8. All items in stages other than ‘Ready’ and ‘Done’ need to have an owner or be moved to ‘Ready’
9. Ensure items in done ‘Done’ are really ‘Done’

Scrum vs Kanban

Scrum and Kanban are methods and principles of how to organise flow of work through their various stages. In a nutshell we can say that Scrum is organised around cycles with a defined start and end, and scope of work, while Kanban is an open ended, just-in-time pipeline where work gets pulled in as resources become available to take on work. Generally speaking boards are used in the same way in both methodologies with differences being found in how work items are managed (which is not covered in this post).

Board Structure

A Board reflects the work ‘pipeline’, i.e. the stages a work item passes through from its initial creation to completion and expresses them as columns. In fact, in the most simplistic — and often ideal form — we blur the boundary between stage and state and have the following columns:

• Ready (to be worked on)
• Doing (being worked on)
• Done (completed)

Most basic board

Yes, I agree, these are not stages, but states, and ‘doing’ could be analysis, coding or testing. But for many teams this may be all they need. After all, by knowing who works on an item, you know what’s being done. Having said this, in practice most teams may want to add additional columns, split ‘Doing’ into a more granular breakdown, tailored to their specific needs, frequently these are

• Ready (near-future scope)
• Ready for Analysis (define)
• Development (implement)
• Integration (any external dependencies)
• Testing (make sure all’s good)
• Done (completed)

Slightly more complex board with meta information

Some notes:

• Keep the number of columns small! Boards with more than 7 columns add more noise and management overheads than they provide benefit. The Board should be used as an easy to use facilitator not a means to manage overly complex processes.
• We should use the ‘Analysis&Design’ column only for activities that happen within the respective sprint (Scrum) or are a direct and time-wise close predecessor to stories that go into development. For most teams this means in practice that this column is either not needed or can be used to identify detailed analysis, clarifications needs etc.
  What it must not be used for is big up-front analysis and design, where, as is the case with most teams, these activities are conducted, quite some time ahead of the item being developed. In this case we may want to consider a separate Board. The reason for this is that we would pile up a potentially large number of items that are in this stage often for long amounts of time with limited relation to stories actually up-coming for development.
  In my experience it is better to not represent these stages and track analysis and design independently if — as most teams I’ve met — you are not extremely lean / agile.
• It is important that we define a Definition of Ready that defines criteria that, only once satisfied, allow an item to be placed in the Ready column which is then being considered ‘good enough’ to be developed.
• ‘Ready’: Items in this column are often listed by Priority.
• In most cases ‘Doing’ defines development, but of course it could, dependent on board structure also include analysis tasks. See notes above.
• Dependent on methodology we may want to consider Testing part of ‘Doing’ or create a separate column, specifically if we want to specific resource or manage this as a quite distinct step. I personally prefer to include testing in the various stages as our mindset should always include testing a intrinsic part of ‘doing’. ‘Testing’ then only makes sense if there are independent testing tasks conducted by agents outside the team, as is often the case in high regulatory environments (finance, medical, etc).
• ‘Done’ is the stage of completed items. It is important to have a ‘Definition of Done’ defining what this means, and avoid moving items into ‘Done’ that are blocked or waiting for external dependencies. In the most radical point of view ‘Done’ means released or at least ready for release. The exact definition is up to the team but it we never must hide outstanding work. For this case, we can introduce a column such as ‘Integration’ which indicates that while this team may be ‘done’ there is a dependency before work is done.
• While we need a backlog, we should only ever have the relevant subset of stories on our boards, never the full backlog as this adds noise and the backlog usually to volatile. Relevant, in the sense of ‘which items are we considering in the near future / this iteration / release’.

Work Items

We create a card for each work item on the board and place it in the column matching its status/stage and move the items as their status/stage changes over time.
Work items are generally speaking Stories. It is important that all work is reflected by a card, i.e. there are no hidden activities so that we are aware of what’s going on and the team’s capacity. So in some cases we may want to track tasks. But again, don’t over-do it. This is for workflow management, not a micro-management tool.

A work item should cover the following information

• Title (Short Description) and where relevant ID
• Parent Story or Epic
• Estimate if applicable
• Assigned worker (see Avatars)

Meta Information

Dependent on need we can also identify the following for a work item:

• Marking Bugs allows us to get a feeling for the ratio of bugs vs features and is a valuable indicator to prioritise our work (assuming that many teams require bugs to be resolved prior to new feature development). Draw a ‘B’ or a ‘Bug’ on the card.
• Marking Refactoring Jobs allowing to track ratio of refactoring vs features
• Marking Spikes as these are time boxed activities and often dependencies for other work items
• Elapsed time can be tracked by adding a marker every day, week or even Sprint to a ticket. While, when automated, this can be used to track estimation against actuals, even when done manually at higher level it may allow pinpointing ‘stuck’ items.

Avatars

Work items must be assigned an owner / worker in every stage (except ‘Ready’ and ‘Done’). On physical boards we can have magnetic icons or symbols indicating the respective owner for each work item. This allows us not only to track who is doing what, but also indicate orphaned items (for instance when colleagues are on holiday)

Physical vs. Virtual

While digital requirements management solutions (JIRA, VSTS (argh), Pivotal, Mingle) will often provide virtual boards, and these should definitively be used as ‘the source of truth’, it is highly recommended to also have a physical board (multiple if working in different locations). The overhead of keeping them updated is minimal (3–5 minutes daily) compared to the benefits which include better communication of work priorities and scope of work and increased ownership and motivation that comes with the ownership and moving through work-stages of physical tickets and avatars.