WIP limit versus batch size, fair comparison?

I thought I rather keep my statements in my blog for future reference. So here are they.

IMO WIP limit and batch size are orthogonal concepts.

They are both important and should be addressed in parallel. In practice I have identified two types of WIP limits so far like I posted in http://thinkinginsoftware.blogspot.com/2014/01/kanban-wip-limit-how-to.html

You need column WIP limits to balance demand versus throughput (queues and buffers).

You need Personal WIP limits because of the poor performance of most of human beings with multitasking.

You need small batches because otherwise predictability will suffer and so you will fail on delivering the promise of the Just In Time system.

Small batching is difficult without controlling variability, which is hard to control for most complex software projects because of the nature of knowledge work.

Balancing demand versus throughput is a necessary step, otherwise you will find yourself "guesstimating" forever. The agile team will try hard to make smaller batches naturally. However variability will impact their ability to do so. As variability is slowly controlled the small batches can flow through the system at a constant pace without the need to create new issues and going beyond the WIP limits, especially the Personal WIP .

So the idea that it is OK to have multiple small tickets assigned to the same responsible person is not good. The limited WIP is needed to guarantee continuous delivery. Otherwise the team will find out that the small issue coming out of an epic might transform into an epic itself. At that point we do not want to open 10 new issues out of that one and get them assigned to the only four developers in our small agile team or put them in a queue that will never get burnt. We need to negotiate the smallest possible part that can be done and which will provide value (MMF). Most likely bunch of those 10 potential tickets can be reviewed as brand new specifications. The team will happily continue delivering value at a predictable pace. The team and stakeholders will be happy with the outcome of the combination of small increments of code AND limitted WIP.