{"id":12226,"date":"2017-03-23T19:09:06","date_gmt":"2017-03-23T17:09:06","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=10059"},"modified":"2017-03-23T19:09:06","modified_gmt":"2017-03-23T17:09:06","slug":"tools-teams-capacity-planning-kanban","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/tools-teams-capacity-planning-kanban","title":{"rendered":"Tools for teams: Capacity planning with Kanban"},"content":{"rendered":"
As practitioners and trainers using Kanban<\/a>, we insist on a few changes in perspective that it requires in order to be effective. One of them is capacity planning<\/strong>.<\/p>\n Kanban, like Scrum<\/a>, assumes that the capacity of the team 1 is fixed in the short term. This leads to the question: how can we use the current capacity in the most effective way possible? This is where capacity planning is useful, and here\u2019s how to benefit from it.<\/p>\n Any team has to do different types of work.<\/p>\n The typical list for software teams includes features, bugs, documentation, and support. Depending on the characteristics of the product, the list becomes even more varied; for eventrix.co<\/a> we identified UX design, visible features, and invisible features<\/strong>. There are differences between visible features since some affect only the UI while others require database changes.<\/p>\n Marketing teams have different types of work too: writing messages for social media, writing messages for email marketing, writing content for the blog, creating graphics, monitoring, reporting etc. Since Kanban assumes the capacity of the team doesn\u2019t change in the short term, and since we know that all these types of work are necessary, the next step is clear.<\/p>\n Let\u2019s assume everyone is currently working on new features and a support request arrives in the team. What is the most effective way to deal with it? This is an example of the level of service.<\/p>\n Support requests will be treated with priority. Someone will stop what they are doing and take the support request. An answer has to be provided in less than 24hrs. This is not surprising since most teams use this policy<\/em>. Let\u2019s look at less obvious situations:<\/p>\n Each of these situations, once it appears for the first time, will require a clear policy and level of service.<\/p>\n One of the key principles of lean \/ kanban is to make things visible<\/strong>. The levels of service are not excepted from this rule; in fact, a team with clear levels of service is much more likely to be focused and effective.<\/p>\n But that\u2019s not all. To make the levels of service visible, you need to…<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n Another name for a swimlane would be a sub-board. Each level of service has its own swim lane, and each swimlane has a different policy and might have a different process.<\/p>\n For example, a software feature tends to have steps like development, review, testing, deployment. But support issues have to go faster through the lane, so they tend to have a smaller number of steps. Some swimlanes have become standard. For example, a swimlane called \u201cexpedite\u201d means \u201csomething really bad happened and we need to act now\u201d.<\/p>\n But we started from capacity planning, so the next step is to …<\/p>\n Since the capacity is fixed, and since we want to use it in the most effective way possible, a decision has to be made on which work is most valuable. Is it more valuable to add new features, x bugs, reduce development costs, solve support issues, prevent support issues etc? The capacity allocation should reject these priorities.<\/p>\n Obviously, the first answer will be \u201ceverything is important\u201d. The problem is, when everything is important, nothing is important<\/strong>. Systems, where everything is important, are not as effective as they could, and good management means deciding priorities and strategies.<\/strong><\/p>\n How can you allocate capacity? Here are a few ways:<\/p>\n If you\u2019re just starting, the best way is to measure first or to estimate based on past data. Also, for fundamentally random activities, like expedite issues, it\u2019s best to monitor the time spent and focus on reducing it.<\/p>\n Because the next and the most important step once you\u2019ve planned the capacity is to…<\/p>\n1. Clarify the different types of work<\/h2>\n
2. Clarify Levels of Service for each type of work<\/h2>\n
\n
3. Associate swimlanes with the levels of service<\/h2>\n
4. Allocate a capacity for each swimlane<\/h2>\n
\n
5. Increase capacity \/ throughput with continuous improvement<\/h2>\n