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!
I offer you here the translation ofan article by Anna Radzikowska, from blog of David J. Anderson, dealing with the subject 🙂
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.
Cruise ships?
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.
2 responses
Hello Olivier, thank you this is a great article!
You talk about creating 3 lead time distributions with corresponding SLAs. Does this correspond to 3 classes of service? Are there Lead Time / Cycle / time / Throughput indicators that are specific for each class of service or is it rather for the entire Kanban system?
Your 3 lead times were grouped by the time spent in the system or by categories (eg "new construction", "change request" and "anomaly")?
In your workflow, isn't there a risk of giving priority to tickets with the shortest deadlines such as "change request" and "anomaly" and of falling behind on "new construction" tickets? ?
Thanks in advance,
Hello William,
Sorry for the delay in response 🙂
Before answering you, I should point out again that this article is a translation of an original post from Kanban University which seemed interesting to share. So I don't know all the context around it so what I'm going to tell you is only my opinion!
Point 1 – Distributions = classes of service?
Short answer: in my opinion, this corresponds well to 3 classes of service which will each have their own indicators.
Slightly longer answer: Indeed, a class of service can be similar to the treatment of a particular type of element which will therefore pass through a workflow potentially different from others. It is the main interest to separate them in different distributions in order to be able to implement improvement actions which will therefore be specific and relevant.
For example: a feature may have a lead time of 5 days while a bug will only have a lead time of 2 days, simply because the passing rules and their processes will be slightly different. It can therefore only be specific to the class concerned.
If you want to have an indicator of your system, you can potentially work on the throughput of elements – independently of your classes – and then work on an average throughput per class constrained by a distribution decided by your environment. For example: 75% of features, 15% of bugs and 10% of technical tasks within 2 weeks. It can become interesting in this case to say that in your system, due to these constraints, you manage to release X functionalities, Y bugs and Z technical tasks in the allotted time.
Personally, I prefer to gauge the selection of elements "just in time" rather than to force my system to distribute. This may require a little more personal rigor but it also gives a lot of flexibility in an environment that is constantly changing!
Point 2: Transition time or categories?
I don't know how this was done in the context of Anna but what I tend to do is group by category first and then gauge split times. Indeed, the idea is to have a similar structure of value contribution that we will then pass through the same process (we limit what we can in complexity / variability (Mura)). Of course this is based on the assumption that the size of the element has little importance on the traversal time compared to the wait times generated by the process.
Now, if it turns out that a new construction and a change request take the same time then they will be able to be part of the same package thereafter but it is an organizational choice that we can make at posteriori.
Point 3: Prioritization?
This is indeed a risk but for me it is totally the responsibility of the prioritization criteria that are put in place in the system. Typically, if your criterion is to bring the maximum value each time, you will potentially take on a longer piece of work that is essential for your client, even if it means not doing everything in your backlog in the end (that's what that we do in Agile). In another case, if you really think you can do everything with your backlog, approaches like GTD or Personal Kanban will actually lead you to take on the shortest tasks before tackling the longest ones – this is based on the principle until nothing will pile up in the meantime 😛
In other words, the selection criteria are important and it is better to share them collectively to have the advantages and disadvantages clearly drawn from them.
I hope I was able to shed some light for you 🙂
Good day to you.
Olivier