WIP vs. Value-adding cards for Kanban in IT operations / IT support

Question

I have a small question of understanding regarding Kanban, because I am currently unsure how to properly map the work to be done. In the last time I have read some blog articles and books about Kanban and how to make work visible. The basic concept and the motives behind it I have understood so far. But I am still missing something to be able to use the whole thing really productively, because I am still very unsure at one point whether I am right here. I am interested in the key phrases Work in Progress (WIP) and Batch Size.

Currently I work in IT support and IT operations, where a Kanban workflow can be implemented without any problems. Due to the two main activities, the work is of course not bound to one workflow, but can or should be represented by several workflows. E.g. we receive several tickets per day about error messages or support requests, which can be mapped very easily in a Kanban workflow. Here, the tasks are usually very easy to describe and can also be completed in a few steps so that the customer has direct added value.

The problem is more in the IT operations area. Here we are also involved in project work, e.g. when new software is introduced, which among other things requires new servers, database etc.

How would I create a Kanban card in this case? If I would create a card, which carries e.g. the title "implementation system XY", then I have this on the board for a relatively long time, since there are different subtasks, which contribute step by step to the result. I.e. this card would load my WIP limit for a very long time, although there can be many waiting times. Waiting for feedback from the supplier, waiting for feedback from the customer, etc. For example, if I write an email which is supposed to clarify various things, then yes I am first forcibly waiting for a response and cannot currently proceed with processing the card.

So what would be the best way to approach this?

Of course, I could create a card for each individual step, which, for example, represents a clarification with the customer. The next card then maps the setup of the server or database, etc. This would of course allow me to work through all the steps one by one and never exceed my WIP limit.

What bothers me about this is that the individual cards don't add any value to the end customer initially, even if they end up in the "Done" column. Sure, this would make the lead time very short, but the customer doesn't get anything out of it since there is no presentable result. Only when the project is completely finished is there a value for the customer. Or do I see this wrong? Maybe it helps to have a "Done Done" column where all subtasks are placed as soon as they are really done?

On the other hand, if I only work with larger work steps, each of which produces added value for the customer at the end, then I feel each time the WIP limit is full so quickly that no further work should be done. Should I have a column where cards are waiting for feedback to be processed further afterwards? To me, it then feels like the cards are constantly moving back and forth between the Doing and Feedback columns.

I just don't know how to put in a proper and low WIP limit if I have to constantly wait for feedback from externals, etc. I just couldn't find anything here yet on how to really model it. Would be great if I could get some inspiration here. How do you implement something like this?

Answer 1

This is a pretty common situation in most work settings - where teams work on a mix of work large (projects/ epics) and small (tasks/ user stories/ tickets, etc.) Work also occurs in "natural" hierarchies - portfolio initiatives - programs - projects - tasks, or epics - features - stories, etc.

Luckily, Kanban is great at "scaling" as it can be applied to ANY level - be it at the project/ portfolio level or at stor/ task level and anything in between. How many levels do you want to use is up to you and your organization - and it is a matter of experimenting and learning.

The question of how granular should your cards be is another great question. On the one hand, you want to be able to control and observe flow. On the other, you don't want to have a very cluttered Kanban board that makes it meaningless to define WIP Limits and show delivery of value. Ideally each card's completion should represent delivery of some value to your customers/ stakeholders.

You can solve these challenges by either having multiple swim lanes within a Kanban board - or even having separate Kanban boards for each level of activity. Within each such lane or board, you should have similar sized and type of cards, so that measuring their flow is meaingful.

Using this design, you can also implement WIP Limits meaningfully. For example, it may be quite evident that at any time, your team cannot handle more than 2 or 3 projects - and your projects board or swim lane should reflect that. Similarly, at the "task" level swim lane, the WIP Limits must reflect the number of deliverables your team can have at each stage of the workflow.

There are tools - such as SwiftKanban (where I work) or Kanbanize - which provide various ways to visualize and manage work in these hierarchies effectively and elegantly. The key thing to look for in these tools is their ability to model hierarchical work definition, support the Kanban priciples effectively and help you measure and improve flow. Here is a visual of how we ourselves manage our themes-epics-stories roadmap and the story development work across 2 separate Kanban boards.

We do releases twice every month and our prioritized user stories move from the roadmap board to the Dev board on a similar cadence. Other types of work that our dev team does are directly added to the Dev board. Our WIP Limit management is tighter in this downstream board, while we use the upstream (roadmap) board to develop "options" based on our own strategic decisions as well as based on customer inputs/ requests. So, our Dev board has well-defined WIP limits that have been refined over the years, that we follow religiously. However, the roadmap board does not have that same discipline :) - and that seems to work fine for us.

Based on your description, I would recommend at least a 2-lane board (or 2 separate boards) - one to track projects and the other to track project and non-project work which your team members actually deliver - stories, tickets, etc. You can define WIP limits only for the latter to begin with, and simply observe your projects lane/ board till you have a better understanding of how you should (or shouldn't) define the WIP limits for that lane. As other factors emerge, I am sure your board design and policies will evolve.

Answer 2

I have dealt with this issue when coaching hardware testing teams, and the solution was to borrow the concept of an "epic" from Agile methods for iterative development. The definition of "epic" I am using is simply a requirement or "user story" that provides customer value, but for legitimate reasons it cannot be completed in a single iteration. It then gets broken into component user stories. Each delivers a measurable output you could theoretically show a customer, but the customer might not care about until the epic is done. (However, each completed user story answers the typical customer concern about whether anything is being done. That is, you can demonstrate progress using the stories.)

For example, a test of a utility meter in an outdoor test bed might last eight weeks. A test under new parameters would be an epic. Story 1 would be configuring the new parameters and starting the test; they could demonstrate to a "customer" (an internal HW design engineer in this case) that the test was properly configured and under way. Each interim check to gather and communicate interim data was a story. And then the final story was final data gathering, analysis, and report. Each story fit within the WIP limit and got "done." However, the epic was not done until all stories were done.

All software dashboard tools I've used had a method for creating epics and connecting stories to them. If you are using paper cards, you could simply note the epic number in a corner and keep an "Active Epics" backlog somewhere near your board. When the last story is done, pull the epic card from it and archive it with the story cards.