12

Starting with Kanban, I'm not sure about how granular my work items should be. While you find lots of concrete recommendations about how to choose the WIP, most of the Kanban tutorials I've read stay quite vague about the size of a work item (= a card on the board).

For planning and estimation, people often recommend to keep the size of an item small, say 2-16 hours. Does the same apply for Kanban? Is there always a 1:1 mapping from my plan to the board?

If there's no best practice or general recommendation, which factors would influence my choice of work item granularity?

claasz
  • 503
  • 3
  • 10

4 Answers4

6

I'd say make items the size they can be easily made to. "Start with what you do now" is one principle of Kanban. So split the work like you do now. "Agree to pursue incremental, evolutionary change" is another principle. Start implementing small changes if you see problems in the way you split work.

Don't get hung up on analysing and designing your "Kanban process" beforehand. Start doing and continue doing things that work and try to fix things that don't work.

simoraman
  • 2,318
  • 17
  • 17
4

I agree with the other answers: Don't worry too much about the size, try it and improve - that's the Kanban way :-).

To still give you some concrete values, here's what our team does:

Minimum size is about 30 minutes - smaller cards cause too much overhead and clutter the board. If something needs to be done that takes <30 minutes, it (usually) gets added to a related card.

We aim for a maximum of one work day, because ideally you don't want to carry an open task to the next day, but that does not always work out. We sometimes have tasks that take two or three days, maybe even a week, but these are outliers, and we actively try to avoid these.

Finally, if you find that a task is larger than anticipated, it is perfectly acceptable to split it even after you started it. Break of the part that is done, change the card accordingly and finish it, and create a new card for what is left. That way you can already have a partial result (e.g. if you must ship), and the remaining work is visible.

sleske
  • 10,095
  • 3
  • 29
  • 44
3

It's up to you, and what you feel comfortable with. I pick a size of "easily understandable and doable". Sometimes that means getting started, realizing it's more complicated and breaking it down more and/or being more clear.

It's just tasks on a list. Size isn't all that important, unless your trying to measure throughput, in which case your probably better off using fibonacci numbers or t-shirt sizings for that instead of hours.

If you're trying to forecast, I'd recommend using either fibnacci or t-shirt sizing for size estimate, and then track how long the difference numbers or t-shirt sizes actually take. Then feed the averages into your forecasting process.

Jim Barrows
  • 385
  • 1
  • 5
0

The following article helped me think about work item size.

http://www.anecon.com/blog/kanban-what-size-should-the-work-items-be/

In summary, one way to determine size is based on how frequently you review progress and who you review progress with (management, peers, or etc).

An example: In my current role as a Solution Architect, I deliver, um, solution architectures for projects. I rarely have a task on my board called “Deliver Solution Architecture for Project X”. That could take weeks to move from WIP to Done and my boss reviews my work every week. Nothing would move. Useless status update, really.

Now, if I have tasks on my board such as, “Build Functional View for Project X”, “Decide front end platform for Project Y”, or “Build architect overview presentation for Project Z”, those tasks will move each week (hopefully).

Also, when you want to go back to understand why Project X’s architecture took eight weeks, you don’t really know exactly what took up the Lion’s Share of your time if the task is too big. Was it the endless meetings with vendors? Was it the countless days mulling over a decision? Was it the tedious and frustrating hours trying to make Visio connectors work properly?

So another rule of thumb I just realized having written the above is: a task should be big enough for you to figure out where you are spending most of your time, since that’s where you probably want to focus on improving.

jppunnett
  • 1