7

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.

5
  • 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. Jul 9 '19 at 10:23
10

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.

1

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.

9
  • 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. 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. 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. 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... Jul 9 '19 at 12:59
0

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:

  • Lead time
  • WiP
  • Throughput *

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.


* actually I should say "delivery Rate" as the author differentiates them, but I'll stick to throughput as it is, I believe, easier to understand.

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.