{"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":"
\n
\n
\n

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

1. Clarify the different types of work<\/h2>\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

2. Clarify Levels of Service for each type of work<\/h2>\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