You’ve decided to create a board to make your team’s work visible: what should go on it? how should it be represented?
Model Different Kinds of Work Differently
A fist clue for an answer to those questions can be taken by observing where the various pieces of work originated: most likely you will find that work came from different people or groups (including the team itself), and that it responds to different needs and expectations. Additionally, the rules or processing steps that apply to different pieces of work can vary considerably.
Very often these days teams call their work “stories”, frequently making little distinction amongst them. The problem with calling everything a “story”, however, is that this hides all that diversity, and also encourages the team to treat everything in the same, homogeneous way. This later makes difficult to reason about the work because you’re forced into a very high common denominator for things that are essentially very different.
So, start by acknowledging that work comes in different shapes: understand your various work item types, and then find ways to make them visually different. Using colours is a very common practice to accomplish this, but other options are possible, such as using tags, sticky notes of different shapes, or segregated lanes on the board.
If you stand back and look at your board, can you clearly see (and distinguish) the different kinds of “things” you work on?
Direct Attention to Customer Recognizable Deliverables
Another important observation is: that what you visualize will heavily influence what you will talk about when you’re having conversations in front of the board (like a daily stand-up.)
When boards contain mostly implementation tasks, the conversation tends to be very inwards-looking, rather than Customer-focused. Moreover, implementation tasks tend also to be associated with particular individuals, which will then cause the conversation to focus on accomplishing individual tasks, rather than team results.
All this can be mitigated by visualizing only “customer recognizable” deliverables (the “things” that team’s Customers are expecting from then, expressed in terms recognizable by them.)
If most of your work is expressed today in terms of implementation tasks, this advise shouldn’t be interpreted as a call to hide that work. Rather, I’d encourage you to trace back the Customer recognizable deliverable that originated those implementation tasks (very possibly consolidating several tasks into one external deliverable) and visualizing them.
If you stand back and look at your board, can you clearly see (and distinguish) the different deliverables your team is working on?
Pay Attention to Ticket Design
Most teams visualize their work by creating a sticky note per item, and then writing on it the name of the item. Often, additional information is added, such us the ID from the tracking system, estimation figures or who’s working on the ticket. However, not much thought is devoted to the design of the ticket itself.
Ticket design goes beyond simply agreeing on a “standard” about what information to display, and where to write each piece; it’s an opportunity to convey rich information about the work that team members can use to make decisions.
It may be important to point out, however, that the intent is not to use the board as a source of documentation. I’ve seen teams attempt to put too much information on their tickets (such as detailed descriptions, acceptance criteria, etc.) That level of detail is better kept digitally on your tracking system or other knowledge bases, using the tickets to reflect information to guide decision making and self-organization.
A good example of this is the practice of showing a table of check-boxes with the usual external dependencies that work of this time is usually exposed to. The check-boxes indicate whether the dependency is indeed needed for this particular item, and whether it has already been fulfilled or not. With this information, a team member can decide who else needs to be involved when starting this piece of work, whether it can be started now at all or not, etc.
This practice can be extended even further to reflect process steps, constraints and other decisions. For example, imagine that you’re on a team that develops an application that is used in multiple geographical regions. The application is developed incrementally, with different regions receiving new features at different points in time, depending on their needs and other local deployment constraints. In most cases, a particular build can be safely deployed in locations that don’t need the new features it contains, but in others, particular care needs to be taken NOT TO deploy some builds in some locations, because local incompatibilities will render the application unusable. When the team plans a release, the situation is analyzed and the table on the ticket is updated to reflect the the conclusions and decisions made.
If you stand back and look at the tickets on your board, can you clearly see information about each piece of work, both about meaning and status but also to inform decision making?
Make Blockers Visible and Memorable
Another common practice is to tag blocked items with a small, red sticky. This has the obvious advantage of directing attention to work that, for some reason, has stopped moving.
A step further consists of recording additional information about the blocker, such as the date the blocker occurred and the reason. Moreover, using a dot on the ticket for every day the blocker sticker stays on the board can give a visual indication of how long the blocker has remained in place, helping the team make decisions about prioritization, escalation, etc.
If all this “blocker stickers” are collected over time, you can use them as input for “Blocker Clustering”, which can lead to better understanding and management of the sources of delay in your process.
If you stand back and look at your board, can you clearly see what work has stopped moving, how long it has been blocked, and what needs immediate attention?
This article is part of a series is based on a presentation I delivered at the Toronto Agile Conference 2018. The slides from that talk can be found here.