How to use Kanban with small tasks?

Question

I recently introduced Kanban in our software development team, but I'm struggling with some things. The main problem I have is how to handle 'small tasks'?

Let me explain some background: We develop some products which are used by several clients. Some clients use our generic product, and some clients have some customized things.

Let's take a practical example from this week. We released the beta version a web-application to a client of us. This client did a test run, and delivered us all his little remarks. In total about 30 point or so. But this points are really small like 'move the logo 10px up', 'change the order of the list'..

How can I handle this on my Kanban board? This is how our current board looks like. The green card is a feature (to be defined userstory), the yellow ones are tasks.

If I create a task for every point of the client's feedback, my board will be overloaded (I have a WIP of 6 in the selected column). The separate tasks will only take some minutes to fix. And also, is it bad to skip some steps of the Kanban board? It doesn't need an analysis or so..

So my question is: do I need to bundle small tasks into 'fixes client x'? Or how to handle such things?

Answer 1

From you board it isn't obvious how your deployment process look like. Is it possible to deploy the app rapidly, e.g a few time a day? It so it should be possible to move small tasks through the board, and just mercilessly move them to the right edge of the board. However even then it would be sort of pain in the neck as the whole process of moving something 10px up will take like 15 minutes or so.

Usually the better idea is to solve such issues independently. The concept I really like is to prepare a dedicated log for such tasks once they're assigned to someone. The log can contain only an id of issue and the id is crossed out once the issue is fixed.

Read more about this solution on Joakim Sunden's site.

Using this approach you get two things:

1. You can still sort of keep track of what's happening as you probably put this log right next to your Kanban board.
2. Whenever "quick fix" appears to be "not so quick after all" you can easily move it to the board for example at the end of a day and just signal the fact somehow in the log.

One more thing which is nice, although it may be useless in your situation, if such small tasks pop in every now and then you can track how many of them you have, when they are submitted, how many of them eventually end up on the board etc. If it is just one time situation however you probably don't need such analysis.

Answer 2

I'm currently reading Agile Estimating and Planning by Mike Cohn and he describes a solution to the problem you are having.

Sometimes, like in your case, a lot of user stories are just to small and in planning are estimated with 0 story points.

In that case, you might want to bundle a number of user stories and bundle them together in one package, so they have a 'weight' and can be planned in as a bundle...

You can write them down on seperate post-it notes, just bundle them together by using a paper clip.

Advantages:

• You gain space on the Kanban board
• You can put them in a proper planning as they have an actual size...

Answer 3

Two separate suggestions:

1. Assuming that these small changes still need to go through the same processes as initial development, then it probably makes sense to batch multiple changes to a single interface as multiple yellow cards under a new green card. This helps ensure that you stick to your defined processes, while at the same time reducing the number of times the same interface has to go through your Acceptance step.

2. Another thing you may want to consider is to add a separate category for these small changes (likely using a different color card on your kanban). Then you can specify a WIP limit for that category that is separate from your existing WIP limits. You can also specify whether this category of work item needs to follow the same rules as your yellow cards or whether the process behaviour is different for them.

Either way, we have found that keeping these small changes on the board is important as it helps give a visual indication of whether these small changes are actually overwhelming the process.

Answer 4

All situations are unique, and depending on what's requested you might need to take a different approach every time, but in similar cases we usually group smaller tasks into larger stories.

We also let the our WIP limits count toward stories - splitting the story into tasks is optional and is often done under analysis.

Answer 5

I just want to point out that bundling tasks together usually backfires, Nist of the time, you may receive all the tasks together but very quickly they each go off in their own direction. One ends up being put on hold, one is impossible to do or just a bad idea, one requires more communication with the client and a bunch are quickly done and are ready to be removed from the board.

I don't use kanban and so couldn't follow everything written here but I'll just say that for small tasks we started using a google sheet. That way everyone can access it, edit it and we have different columns to express who is responsible, what stage it's at and how urgent it is.

It's simple and it's working very well.

Answer 6

In my company we create to-do lists for quick tasks like you described. This way you do not waste time for creating separate card for each task and just mark/tick is as done on a list.