Arrow Kanban for a healthy backlog management
In this post, I choose arrow kanban as one of the best examples demonstrating the use of different Kanban techniques. It is also one of the best visualizations of kanban boards to spark creativity. So let’s dive in.
Pains of backlog leader
I am using the term backlog leader just to stay away from Agile-specific roles, and backlog management is not broad enough to be a role on its own, it’s a responsibility. Yet every team, every organization, and even personal initiative ends up having a backlog of things that will bring us closer to the end goal. Hence, each backlog needs a leader to ensure the success of the endeavor.
From the very beginning of creating a backlog to continuous backlog management, this so-called backlog leader will start hurting. I have preselected in my opinion 4 most common pains, but the final list should not be limited to them only.
Reliable process
If there is no repeatable process with well-defined steps, having a predictable outcome for each backlog item will be a gamble. On the other hand, leaving for vacation or getting sick will become impossible because nobody else will understand this ambiguous process of yours.
Backlog size
This is a problem that can grow over time. Yes, the more stuff you have in your backlog, the more demanding it will become. You might end up swimming in a grand patch of garbage instead of a well-structured work pool.
Prioritization
Closely coupled with backlog size, yet deserves a separate mention. How easy it is to decide on the most important things and how transparent priority picking can be? How much time does it take to reprioritize?
Time to market
It does not matter whether you are doing a space program or renovating a kitchen, the sooner the results the more valuable they are. Hence, time to market is the biggest pain which encapsulates the majority of other pains inside itself. Process efficiency, maturity of practices, speed of decisions, amount of waste – all of these contribute to time to market.
Medicine for the backlog leader pains
Prioritization pyramid
The dead simple thing which can bring significant improvement. Narrow down your priorities capacity based on how high it is. This magic triangle has the only magic thing – it is physically/visually limiting. So fewer items in top priorities than at the bottom ones.
Of course, we will need one of those. It will serve as our downstream / delivery process visualization and management tool. Each team or individual will structure their board uniquely.
Kanban metrics
In order to answer very important questions such as “when will it be done?” or “how much time will it take us to finish 20 items?”, we will use Kanban metrics such as lead time, cycle time, and throughput.
Cake and retrospective
Last but most fun – eat a cake and look back to see what went well or what can be improved. The engine and fundamental forward pushing force – we will learn and act on those learnings all the time. This is how you make progress.
Building the arrow Kanban board
So now we are aware of both problem space and potential solution space building blocks, let’s construct arrow kanban and see how it works. And by the way, the arrow is just a visual cue to make it more sticky in your head. You can construct arrow kanban in any kanban board which has true kanban system features. We will also see that in the latter part of this post.
Taadaaaa! This is our arrow Kanban board which all the bells and whistles built-in. Might seem detailed at the first glance but let’s walk it over and you’ll see how easy it is.
Upstream – our work input process where we have full freedom of moving things around. It is a crucial part where we must ensure the quality of work and knowledge in order to maximize the success of it being finished. Here we can reprioritize and move things both forward and back. We will use WIP limits to limit each priority level to create logical congestion.
Commitment point – this is the crucial point where if backlog items move to the right of it, it means we are fully committed to finishing the item and it will not be pushed back.
No dependencies – the golden rule for minimizing blockers or pushbacks – do not commit to work that has unsolved dependencies. This is a true waste producer if not tackled properly.
Delivery (aka downstream) – this is our execution kanban board where we also use WIP limits to reduce multitasking.
Classes of service – each item color symbolizes a different class of service, for example: incidents (red), tasks (yellow), projects, or initiatives (blue or green). It will be very useful with metrics and also visual separation.
Expedite lane – for incidents and work that has diminishing value over time with high urgency/impact on the business, we want to create a fast track. Which will allow solving things at hand. This is the riskiest part and it requires limiting as well. Otherwise, people will see how easy it is to abuse the expedited line and garbage will start flowing through it.
Done + retrospective + cake – finished work will pile up and we will use it as a trigger for our retrospectives. Let’s say we limit our Done column to 20 items, once we finish that limit – it’s a trigger to do a retrospective and eat a cake for celebrating a step closer to our goals.
Cycle time – we will measure how much does it take to finish items once we commit, this will give us an understanding if we get better or worse once we start changing things in our downstream kanban.
Lead time – we will measure how much does it take from item creation to the actual finish line. This will give us an understanding if we get better or worse once we start changing things in our upstream kanban.
Throughput – we will need to understand how many items we finish during some unit of time like week/month, etc. This will help answer questions such as “when will it be done”. We will use classes of service to separate throughput per class since items of the same class tend to be more lookalike. Meaning we compare apples to apples and not apples to potatoes.
So this is it. This is the full showcase of techniques and the final product – arrow kanban.
Real Kanban Board example of arrow Kanban
Click on the link to see a real implementation of arrow kanban in action.
2019 - Present Co-founder and CEO @ Teamhood.
2015-2019 Head of software engineering department at Danske Bank.
2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course
2011 - 2015 Managed numerous smaller IT teams at Prewise.
Co-founder of RaveIT, Eylean, No Brakes Games
Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products.
MSc of Software Engineering at Vilnius University.
Hobbies: Racing, MTB cycling, Windsurfing
