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?


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.


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?

  • 1
    There is one important thing missing from your question: why is this important? There isn't an agreed upon convention of how you should size the cards. It depends on your work flow and what issues you are facing or what parameters of your process you want to intervene on. So what's the situation you trying to solve and think sizing of the cards is important for? People might provide better answers if they know a bit the larger context – Bogdan Apr 23 at 9:51
  • 1
    Flow is optimized for batched items that are within one standard deviation of the median. Significant changes in story size will perturb flow, and make your process and cadence less reliable. – Todd A. Jacobs Apr 24 at 12:44
  • thank you @Bogdan I have edited the question to clarify my situation – nonthevisor Apr 25 at 8:38
  • I'll also add that INVEST and agile best practices suggest decomposing work items to 1/2 to 2 days. Anything more than 2 days of effort is much harder to estimate, and less likely to be simply "done" or "not done." Having 60% of your cards 40% done accomplishes nothing in a pull-queue system like Kanban. – Todd A. Jacobs Apr 26 at 15:08
  • @ToddA.Jacobs if you source those numbers and maybe add a little explanation, you could post it as an answer – nonthevisor Apr 27 at 13:18

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.


  • thank you for your answer, I never heard of ToC before, but it sounds interesting. could you maybe explain how such a "slowest step" could look like? as it is, I am having trouble deciding which step is the slowest. let's say we have a standard "backlog, developing, test buffer, testing, done" flow, how would we implement the ToC solution? – nonthevisor Apr 27 at 13:17
  • @nonthevisor, in most projects this would be Developers. Either remove some of them from the project or add more QA. The goal is to have QA slack from time to time. – Stanislav Bashkyrtsev Apr 27 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.