The Kanban Story: Skipping Part of Process by Pawel Brodzinski

The more complex your process, and your Kanban board, becomes the more likely it is you’re familiar with the following situation: you work on a task which doesn’t go through each and every stage of the process so you’d like to skip one of two of them.

Consider a very simple board.



What happens when we build a feature (feature E) where there’s nothing to be documented? What to do with a sticky note on the board? Should the process be changed?

What happens when we have research task (feature H), which we don’t know outcome of, and we want to put it on the board? What if after research (development) we decide that it’s not going anywhere to a product? I mean we’re done with development but we don’t plan to do anything more about the task: neither testing, nor documentation, nor deployment.

Before we go further I have another question: does this specific situation happen frequently? If not then don’t even bother. If it is an exception then treat it like exception. You don’t get points for following the process religiously.

However, if it happens at least from time to time you should probably stop and think. One idea is redesigning the board in a way which incorporates such situation. Except you’ll likely end with conclusion that you have two different processes out there: one for regular development and another for research (or no-documentation development). So we come back to a question what to do with that?

Well, you can split tasks into two boards but this way you either loosen your limits, e.g. additional limit for one research task, or you lose some flexibility, e.g. splitting your current limits among two boards. Either way I’m not a fan of the approach.

What we ended up with in such situations was just skipping parts of the process which were irrelevant. No documentation? The sticky note goes directly to documentation done column instead of testing done. No follow-up after research whatsoever? Um, seems like we’re done done with this one so we should probably put the sticky note in the last column.

Again, we don’t get points for being ideally adjusted to the process. The board should reflect the way we really work and it shouldn’t constrain us too much. If this is how things really look like why shouldn’t we just show it?

Skipping parts of the process on the board for specific tasks is an option to consider. One advice though: as with any other movement happening on the board, make transition criteria explicit. If something goes directly from development to done column everyone in the team should be able to tell precisely what it means. And of course the answer should be basically the same each time.

If you liked this story make sure you check the whole Kanban Story series.