Recently Kate started our new cycle: “Debunking Kanban Myths” with article “Myth 1- Kanban board means Kanban method”. Today I would like to continue with Myth #2: Kanban is perfect, when you have no strict deadlines, but you move tickets only. Otherwise… well, better use something else. Reducing Kanban to creating board and moving tickets is the most common misunderstanding I meet when talking about this method to people who have never had a chance to apply it with the full range of practices. This leads to the perception of Kanban as a “tool” for software maintenance teams or the others (not entirely precise) groups who want to have some fun with post-its and markers, but with no deeper need for change. Actually, by focusing more on the flow rather than on the strict timeboxing or keeping deadlines, Kanban is able to address the needs of most of the groups or teams (if not all of them), no matter if they work with tight deadlines or they have full control over the delivery date. How to achieve that? 1. Identifying classes of services by their business impact (the classification below comes from “Kanban” book by David J. Anderson): Expedite – an item that requires immediate teams’ attention, is associated with the cost of delay making it the first priority; usually violates work in progress limits or has separate, dedicated lane on the board. The terms under which item becomes “expedite” require special attention and policy to avoid ticketing all items this way just to speed up the work on them. Fixed delivery date – an item, which has usually no cost of delay until certain date – by when it should be delivered; however the “fixed date” items are normally announced much earlier, which helps teams to plan accordingly. The examples of “fixed delivery date” items are old versions of software that are no longer supported or regulatory changes in finance that may require additional reporting. Standard – items that require normal treatment, usually there is (there always is) some urgency on them, but they don’t need exceptional prioritization (in my case it was 85%-90% of items on the board depending on the project). They can be divided further e.g. by size to assess their expected delivery time. Intangible – the lower class of service, for me – the most tricky one. “Intangible” items are important – but somewhere in the future, which sometimes is not strictly precise or is so distant that in the world of items “for yesterday” no one really cares. And that’s the tricky part as time flies and “intangible” work tends to become “fixed date” or, even worse, “expedite”. Any time an “intangible” item says “hello” to my backlog, it turns on the red light in my head. 2. Kate has already described how work items types can be visualized on the board. Think about them especially in more heterogeneous teams, who are not dedicated to one work type only. I had a team which supported very different activities: from soft development, through ad hoc testing, analysis for standardization and system maintenance tasks. By identifying work item types and adding class of service to each of them we’ve been able to prioritize the work effectively. 3. Each activity has its deadline, either externally specified or defined by the team. We don’t work into perpetuity. What’s important is to be able to set these deadlines and to do it consciously – not through the “gut feeling”. Kanban comes with helping hand with its metrics (measuring WiP, throughput, blocked items or work efficiency) – and among them my beloved one: lead time. Lead time distribution together with outliers analysis is a powerful tool supporting reliable commitments. How do you deal with deadlines? Can you share your experience?