A recurring question when talking about flows is to know the size of a work item. Indeed, it is assumed that the larger an element, the longer it will take to go through the process. However, in Kanban culture, this is not entirely true!
Nice reading to you!
Kanban Evergreen: the size of a ticket
Each Kanban trainer has their favorite set of questions that come up again and again during each of their sessions.
Here is my personal list:
- Can items be moved backwards on the Kanban board?
- How do you set your very first work-in-progress limit?
- What should be the size of the ticket in the Kanban system?
- Should pending items (parking lot items) be included in the work-in-progress limits?
If you've ever asked yourself any of these questions, here I am with the answers!
How big should a ticket be in a Kanban system?
Issues on a kanban board should represent work items that are meaningful to a customer, ie. that they must reflect a request. If I ordered a pizza, the ticket on the board, visible to the customer, should represent the request for a pizza. If internally the chef asks the cook to cut onions, then the service provided is onion cutting and the receipt should represent this request.
Tickets should always represent the request that has been made to the service provider.
The size of the ticket does not matter. What is “size” anyway? Is it the number of hours spent? Or maybe the story points assigned by the developers?
The tickets go on the board and they move. Although it may be counter-intuitive, Kanban doesn't really care about item sizes. Understanding the types of work items you have in your department is a more natural way to group them than to estimate their size. To guide you, what you want to see is your ticket circulating. If an issue hasn't moved on your board for a few days or more, but some work is still done, then maybe you need to consider a two-tiered board: with finer-grained elements from greater customer demand.
The key is to see the stream and to have tickets representing deliverable significant pieces of work to the applicant.
So how do you handle estimates?
Do not estimate!
This rule has been true since the very first Kanban case study at Microsoft XIT in 2004. Do you remember how much time they wasted delivering estimates that were never met rather than focusing on the real thing? work that brings value?
Easy to say: “don't estimate. » What should you do instead? With Kanban, you forecast using historically observed lead time. Lead time is not correlated to size, or complexity because flow efficiency is almost certainly very low. The biggest influence on lead time is lead time and queue management. (or the associated lack). The size of a piece of work is not useful information even if this estimate was very accurate.
Identify different types of work items
I remember working in building products for a finance department. The first type of work item we had was " new constructions“. After we started delivering product increments, we started getting feedback. This resulted in a new type of work item: change requests.
Defects were also resolved immediately as they affected the customer's visible product. We realized all these nuances by analyzing lead time data and listening to customer feedback. By noticing a multi-modal distribution of lead times and by analyzing lead time and data points, we no longer detected a single type of work item, but 3. We then created 3 lead time distributions from the first and established corresponding SLAs.
The “size” of these items was a natural consequence of understanding these types of work items. By grouping those that were similar in nature, they were eventually grouped in size.
The example below from Kanban Systems Improvement training explains how you can identify and read multi-modal data:
Items with truly different sizes will be different types of work items. If you never see a ticket move, then maybe it's too big. Or maybe you need a portfolio chart or a 2-level hierarchy to see things happen.
You are looking to identify consistent types of work, it can even be something huge. Let's take another example. If you build cruise ships, a ticket for a cruise ship goes on the board. If you're in the cruise ship business, then the time and energy it takes to build one is known and understood. With one boat, then the next, then the next, we can start building a histogram of lead times, since they are all the same type of work.
Then one day Richard Branson passes by and says to you:
I am thinking of buying a cruise ship for Virgin Voyages and thought of ordering from you. If I order this week, when will it be ready?"
If we know what we are doing because we are a maturity level 3 or 4 cruise ship construction company, we can give him an answer.
We could say :
We could have it for you for July 2024 Richard. What do you think ? And we'd know that's a promise we could keep.
This is a significant change between maturity level 1 and maturity level 2: you start to see different types of work items.
What should you do?
Developing analytical skills, paying attention to your environment and the language people are using could help you identify the types of work items in your process.
There is more !
Imagine that you have a flow efficiency of 2% in your organization.
This means that only 2% of lead time is actual work: where things are in an activity column and really being worked on. 98% of time is waiting. So the size of the ticket and its actual work are trivial numbers compared to its lead time. Therefore, you are estimating the size of the wait or waste time, not the size of the current job.
For the same type of work item, the efficiency of the flow will produce more variability than the size itself.
So what should be the “size” of my ticket?
Let’s focus on pragmatic advice to this question:
- Don't bother estimating the size. Let the ticket flow through the system. Analyze it as an upstream option and use lead time data to decide when to start working on it downstream.
- Understand your work item types. Listen to what people are saying, what language they use when talking about processes and the work being done.
- The work item should be “small” enough to allow you to see its progress (or lack thereof – blocking, waiting dependency). If your item sits for a few days/weeks in a state, and you lose dependency tracking because it's still "in progress", then look for something smaller.
- Your work item should be "big" enough not to create overhead. If you're spending more time creating and moving something around your system than actually working on it, then you need a higher level.
- Use ticket design to help you make decisions with confidence. The idea is that when you watch it, you know "what's going on" without having to deliberate about it. Of course, this perspective, like anything, takes time to experiment with and you may need to experiment with different approaches. Be patient. Improve collaboratively, evolve experimentally.