Capacity planning when using Kanban-base/Lean development

Question

We are currently using Scrum to help develop a set of software libraries in C++ and C#. The nature of the domain is such that we need to be pretty reactive to changing requirements - so much so that sprint-planning often ends up being a waste of time due to the high level of emergent work. I'm thinking it's time to switch to a lean (kanban) development model instead of Scrum since this has worked reasonably well for us the past.

Also on my mind though, is that I'd like to be able to make a case to my managers that my team is understaffed. I'm unclear on how to do this effectively since lean methodologies espouse very minimal time spent on task estimation. I should be encouraging our customers (and my managers) to focus on priority of work rather than how long each feature will take. Thing is, we still have a hard deadline to hit and they want to know we can hit it. In order to commit, I feel the need to measure things and calculate the staff I reckon I need!

The problem is that I don't know how I can make an argument for more staff if my team is using a process that focuses on prioritisation - I'd need to estimate all the work we're expected to get done and then present the numbers to demonstrate "we'll need X more people".

In essence I suppose I'm asking whether anyone has any good tips for measuring, and making a case for changes in, team capacity when you have adopted a lean, agile process?

Answer 1

In Kanban you can set up "classes of service" and assign a "service-level agreement" to each.

For example, issues that are blocking a customer are #1 priority, and might even cause us to exceed WIP limits and switch from in-progress work to satisfy. Such work will be done within 3 days 90% of the time. (Such agreements should be derived from real data, which you'll start to accumulate if you record item state each day, e.g., in a cumulative flow diagram.)

Along with classes of service and SLA's, you can also stipulate that 20% of the team's time should be spent on these urgent ("expedited") issues, 60% on normal work (feature development, for example), and perhaps 20% on continuous improvement, hygiene, technical stories, etc.

If you can get management agreement on this, and then if you can show that you're instead spending, say, 60% of your time on urgent firefighting issues, then you can prove that you need more team members to get "normal" (expected) stuff done.

Answer 2

Have you a detailed features list ? If it's the case you can processed like this:

• List your features and for each of them, list your stories.
• Then with your team try to estimate stories: Compare each stories with a similar functionnality to estimate it. You can also use some estimation tools like planning poker.
• Compute the delay and try to to figure out what is necessary for your next release with your manager. Involve him in the decision and he will see by himself if you need to remove some feature or involve more people in the process.