User Stories are generally written using INVEST method; the E meaning easier estimation which does not apply to Kanban and S meaning small enough to fit into iteration which also does not apply to Kanban.
The rule of thumb is generally that a story should move through the system in 2-3 days.
I can’t find out why though.
If user stories need to be small for Kanban, why do they need to be small?
Is the reason due to WIP limits? This is even more confusing since WIP limits are empirical.
In a word: feedback.
Whether you’re coaching a soccer team, flying a drone, planning a city, or writing a dissertation, the sooner you can get feedback, make adjustments, and get more feedback, the more successful you’ll be.
In Kanban, you get feedback by completing stories and observing how they affect the system. A smaller story can be done faster, getting you feedback sooner and more frequently.
There are various forces that limit how small we can make a story in practice. In your situation, that limit may be 2-3 days, which is fine. No matter where you are, you should always be looking for ways to reduce the batch size and cycle time without unwanted side effects.
Many of your ideas are based on faulty assumptions.
S meaning small enough to fit into iteration which also does not apply to Kanban
and
The rule of thumb is generally that a story should move through the system in 2-3 days.
You link to the Agile Alliance page that defines INVEST. However, that page links to the XP123 blog post by Bill Wake that captures the original definition of the INVEST mnemonic. If you look at the original definition of "Small", it doesn't mention iterations at all. It does say that Stories "typically represent at most a few person weeks worth of work", but some teams may choose to make them smaller.
The S from INVEST should still be applied to whatever your work item when applying kanban, but how big S really is depends. You are right that you can't use your iteration length as a boundary for the size of the work item if you are following a leaner approach, but you would be able to if you are applying kanban to Scrum.
the E meaning easier estimation which does not apply to Kanban
This is a relatively common misconception. There are two techniques around estimation in kanban approaches.
The leanest approach to estimation is to decompose the work into roughly equal sized chunks, where each work item that moves across your kanban board is roughly the same size and you can simply count number of work items and time to progress. However, you can also use relative measures (such as story points) or time measures (person-hours) as well, but you would need to consider these when computing many of the metrics commonly used in a kanban system, which adds complexity and introduces additional room for error. My recommendation is to work toward the first approach, but if you are transitioning from something like Scrum, it may take some time to get there.
Both approaches are still estimation, though. If you aren't thinking about the size of the work, you aren't able to determine if two pieces of work are roughly the same size.
The point of David Anderson's comment is to consider why you are estimating and your current approach. How much time are you investing in estimating using your current technique? How much value do you get from it? Why are you doing it? I think it's much like the #NoEstimates movement - it's not opposed to all estimates in all cases, but rather a drive to think about what you are doing and why you are doing it.
But, to the heart of the matter:
If user stories need to be small for Kanban, why do they need to be small?
Is the reason due to WIP limits? This is even more confusing since WIP limits are empirical.
There are two reasons for small work items when applying kanban: feedback and predictability.
Smaller work gets done faster. It goes all the way through the value stream and delivered to the next stage in the process. You can get feedback on the work, which would allow you to change your backlog based on the changing situation. You can also get feedback on the process, finding bottlenecks or opportunities for improvement based on how long the work was in each activity.
If the work is equally sized or you can easily tell the relative size, as work moves through the value stream, you can predict how long it will take to go from an arbitrary point in the backlog to done, assuming it's not reordered. Or you can tell how long a work item typically lives in a particular stage of development. Equally sized work makes this much easier, but after some work items have passed through the process, you can use historical data to make predictions about new data. And if you're following an empirical process and inspecting your processes and methods regularly, you are hoping to improve, which could be time reduction.
Actionable Agile Metrics for Predictability: An Introduction by Daniel S. Vacanti is a good intro to metrics around kanban and other lean approaches. I found it a little dense, but very informative.
If user stories need to be small for Kanban, why do they need to be small?
TL;DR: Little's law: Small stories means improved Lead time.
Without entering into the debate whether Kanban is agile or not, I'll focus my answer on David Anderson's Essential Kanban Condensed book. To be precise, on page 15.
In short, there's 3 aspects that are functions of the other two:
One of the (common) objectives when implementing Kanban is to improve Lead time. The average Lead time is the average of WiP / average of Throughput. Usually one manages the WiP to improve lead time, but if you can also reduce the story size, your throughput will be higher and thus, your lead time will improve.
Example:
My team measures work in units of work called Tiago's points (TP). My team delivers 1 Story per week. This story was fairly big, I'll say it was a 5 TP. My lead time is 0.2 Story/day (or 1 Story/week).
Now, I've discovered how to better break down stories. Instead of one Story of 5TP, I have 5 Stories of 1TP each. What is my Lead time now? My lead time now is 1 Story/day (or 5 Stories/week).
That's why, in Kanban, we want to have small stories. To improve lead time. And by improving lead time, you reach all the benefits other answers already provided.
