High-level and low-level tasks in Kanban

We use Kanban to coordinate our projects and tasks. Kanban is focused on visualizing and improving throughput, that is, making projects (high-level) and tasks (low-level) go through the system as fast as by limiting work in progress, which in turn minimizes waste (time and money).

Our field of work is IT operations and we’re generally quite busy with fulfilling requests from our internal and external stakeholders. Most of our tasks are quite small, about 1-4 hours each, and produce value immediately. We can generally get these done (“through the system”) quickly without having to stop in the middle and can then forget about them. However, we also have bigger tasks that tend to take a lot longer, maybe 8-24 hours of focused work and often involve multiple persons.

It is these big tasks we have challenges in completing efficiently:

  • In most cases we won’t be able to finish them without having to jump into something else in between due to stakeholder requirements such as urgent tasks or contractual obligations.

  • Because of the above, the motivation to even start a big task is low.

  • The world may move on while we’re working on the task.

  • Waste is produced: we need to write detailed notes and/or spend time figuring out where we left off when we resume the work.

A good goal for a task is “when it is done, you can forget about it”. This usually means that you’ve also managed to produce something of value to somebody.

To improve our throughput we’ve split our Kanban into high-level and low-level flows:

  • On high level we work on epics. Epics can be thought of as mini-projects that consist of several smaller tasks.

  • On low level we work on the small tasks. They may or may not belong to an epic.

We’ve identified several ways to construct epics:

  • Linear phases of work. For example: research, experimentation (PoC), development, testing and deployment. These phases are completed one after the other. Each phase produces a deliverable, but the customer value tends to materialize at the very end. The intermediate deliverables (knowledge, documentation, code, test results) just make it easier to forget the previous phases.

  • Goal-oriented: the tasks in the epic are related, but the tasks don’t have to be done in order. Value proposition is at the end. An epic like “recruit a devops” is such an epic: lots of things to do, but the individual tasks can, for the most part, ordered freely.

  • Common theme: each of task in the epic tends to produce value immediately. An example of this might be “website improvements #1” where several, individual small issues with the website are fixed. The main purpose of this type of epic is to focus resources to an area where we need to improve.

It is very important to limit the number of epics that are in progress at any given time. Each epic that’s going on increases the changes that somebody will need something from you and interrupt your work. It also means reduced throughput as you’re working on more tasks in parallel. It is like starting multiple Scrum sprints simultaneously - a practice you’re unlikely to find anyone recommending. But with Kanban and its less strict rules (“limit work in progress”) it is easy to forget things like this.

Creating low-level tasks seems easier, but the devil is in the details:

  • One thing per task. Do not create tasks such as “do thing a and b” where a and b are not interdependent. That just increases the chances of the entire task getting blocked or delayed for no good reason.

  • Define the goal clearly: if the description is ambiguous how do you know when you’re done?

  • Use classes of service: it may be useful to categorize tasks by a class of service such as “Standard”, “Intangible”, “Fixed delivery date” and “Expedite”. This helps with prioritization and makes it less likely that you need to be reactive rather than proactive.

  • Focus on value: try to make the task such that at the end you have produced something of value.