How to size Kanban cards

Question

Problem

When creating Kanban cards, I don't know how I should size them, i.e. if I have one task that I estimate to take a week and one task that should take only half a day, should they both just get one card, or should I somehow split them into cards of more equal sizes?

Situation

I don't work in a group which uses agile project management. I am trying to adapt this kind of thinking and working to optimize my own output, and if that goes well, I want to propose agile methods to my team.

What I found

I have found some related questions/answers, but none exactly like mine.

• This answer recommends using one card and then coding it for size, following an S,M,L approach.
• This answer says that size only matters when using WIP limits, but then cards should be of similar size.
• This answer recommends bundling small tasks together on one card.

Question

Is there a commonly agreed upon size for Kanban cards, and if not, is there a recommended way to determine that size on a per project basis?

Answer 1

Just-in-Time (I wish people stopped saying Kanban) requires all tasks be of the same size. It doesn't matter which size it is (though usually smaller sized tasks are easier to manage & predict), but there must be only one. Otherwise you can't measure WIP limits in number of tasks, which in turn means you don't know how to balance the work across the stream. Rendering JIT useless in this situation.

This is the reason Kanban by D. Anderson says that this method makes sense only for maintenance-phase projects. Active-phase projects can't be easily predicted and the tasks vary too much.

Another problem with WIP limits in Software Development can be demonstrated by this example: imagine you have 2 tasks, both of them take 5 days. But 1st one requires 1 day of Dev time and 4 days of QA time and the other requires 4 days of Dev time and 1 day of QA time. Some tasks are more complicated from Dev perspective, others - from QA perspective. And this makes WIP limits brittle even for tasks of supposedly same size. The only robust solution would be to estimate tasks separately by different parts of the team and set limits in hours/story points/whatever you used to estimate. But this makes the process too heavy and still relies on the team's ability to estimate.

But there's a simple solution inspired by Theory of Constraints which solves all the problems: if you make your 1st step in the stream the slowest, then you don't need WIP limits at all (this effectively makes JIT=TOC). You don't need to balance the work because there's no step in the steam which can overload another next steps.

So you have a choice: an easy way to balance the stream better or a hard way of keeping the tasks of the same size.

Literature:

• The Goal by Eliyahu M. Goldratt
• Kanban by David J. Anderson
• Detailed explanation of the idea