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.

  • I believe some of your statements to be based on false assumptions. Where have you read that the "S" in INVEST refers to fitting in an iteration? Or that estimation doesn't apply in Kanban? Or that a story should move through the system in 2-3 days? – Thomas Owens Jul 8 '19 at 22:27
  • Agile Alliance: agilealliance.org/glossary/invest – user32613 Jul 9 '19 at 6:20
  • “Only classes of service related to riskier items should involve wasteful activities such as estimation” Kanban, David J Anderson – user32613 Jul 9 '19 at 6:29
  • Thomas that is absolute nonsense. How can you have a potentially releasable increment if the user story does not fit inside an incremental timebox? We both know that you know this. I don't why you are arguing this point when it is not in line with any of the Agile patterns that are taught/advised/published. – Venture2099 Jul 9 '19 at 10:23

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


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.

  • 1
    Sorry Thomas, but that is untrue, almost all Agile thinking is that user stories should represent less than 2 days worth of effort and they should ALWAYS fit inside an iteration. That is generally accepted guidance form Mike Cohn, Bill Wake et al. Whilst you are right, some stories do not, that does not mean we should advocate for 3 week long user stories. I think you also know this but you are taking a devil's advocate approach which is a disservice to the OP. Everyhting he posted is in line with everything taught by the Agile community. – Venture2099 Jul 9 '19 at 10:14
  • Why would you estimate Kanban work in story points when cycle and lead times are the primary method of empirical measurement? Where would you even estimate since Kanban teams do not have formal timeboxes within which to place planning and estimation ceremonies. Unless you are asking individuals to estimate each task as it arises? The main reason for sizing user stories/product backlog items in scrum is to be able to plan releases and prioritize. When you know the size of a product backlog item you can plan for approximate deliveries for your features. – Venture2099 Jul 9 '19 at 10:19
  • Kanban, by definition is for unplanned, variable work based on immediate priority. Whether sized or not, if it is the highest priority item in the queue, it needs done. I think you also know this, you just want to highlight the niche cases and I am not sure why. – Venture2099 Jul 9 '19 at 10:20
  • @Venture2099 I've updated with clarifications. Everything here is based on my experiences coaching software development teams and organizations, benchmarking opportunities of other teams and organizations, attending presentations and talks about software engineering methods and practices, reading various publications (including the people you mention, among others) and more. I am not taking a "devil's advocate" approach - I am presenting the things that I have seen work and that I believe are the best approaches with my experience. If you have other experiences, please write your own answer. – Thomas Owens Jul 9 '19 at 11:33
  • I can write my own answer but that does not preclude me from disagreeing with yours. You know full well where the OP got the idea of user stories should ideally take less than 2 days. Years and years of agile consensus. So why try and be obtuse? Instead of asking for evidence from the OP, why don't you provide some evidence that User Stories can take 3 weeks and that is optimum... – Venture2099 Jul 9 '19 at 12:59


For example, consider the following user story: I want to be able to install the software.

It's pretty much irreducible, so that's what it's going to be. But it's probably going to take longer than a two-week cycle.

(This was the user story when we got tired of building the software directly on the demo machines.)

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.