Use of Operations Research to plan optimal capacity for a Kanban team

Imagine you are responsible for setting up a new Kanban team to develop a piece of software. You have the following contextual background while forming the team

• Requirements are progressively elaborated and you expect on an average 3 new feature requests per day adding to the "To Do" list
• New requirements are likely to follow a Poisson distribution. ~ Pois(3) 
• Since new feature arrival follows a Poisson distribution, naturally the inter-arrival time will follow an exponential distribution
• The feature development distribution would mimic the inter arrival time and follow an exponential distribution as well (i.e in Kanban model, you move the card from "To Do" to "in progress" as soon as you are free to take up the card)
• You have flexibility to change the team staffing to increase or decrease the average service time

Problem Statement:

What is the optimal feature development "capacity" you should plan for to minimize the time between a feature arriving in "To Do" list and moving on to "In Progress" list (i.e. The "Wait time" for a feature). 

Solution - 1:

The following points are evident through application of common sense / gut feel

• The minimum capacity should be an avg 3 features per day ( same as "feature arrival rate"), otherwise the "To Do" list (or backlog) will grow on to inifinity
• There is cost associated with increasing capacity. We need to make a trade off between minimizing the wait time in "To Do" bucket and limiting the cost development to an acceptable level
• May be we can pick a capacity anywhere between 5 or 6 features per day

Solution -2: Application of Operations Research \ Queuing Models

The above scenario reflects an M/M/1 queue model. i.e

• Arrival rate follows Poisson distribution
• service rate (= Feature development rate in our case) follows exponential distribution
• Single server (one Kanban team in this case)

average wait time in an M/M/1 queue (refer to this paper) 

                                                                = (Arrival rate)/ service rate * (service rate - arrival rate)

in our case, arrival rate is = 3 features per day. We have option to vary the service rate (= # how many features can be developed in a day) by changing the team staffing. Given below is a plot of the Wait time as a function of service rate (= feature development rate)

The following points can be inferred from the above plot

1. We must plan for capacity to develop >3 features per day, otherwise the wait time in "To Do" list can grow for ever
2. Having a capacity to develop higher than 7 features per day gives diminishing returns. Having a capacity to develop 7 features may just be good enough

To Summarize, most of the functional managers, team leaders use their gut feel (Solution #1 above) to do capacity planning. In most of the situation, the gut feel gives us good enough results. However there are certain critical situations where the business impact is so high that we require a more scientific approach to base our decisions. As we demonstrated above in solution #2, the appropriate Queuing model can be applied to make more informed decisions.