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. 

Using Term Document Matrix

Problem Statement:

Let's say you have a number of documents. Each document has a number of words (we refer them as terms). The problem is to identify two documents which are most similar.

Given below is one of the solution approaches

Use of Term Document Matrix:

Each row of a Term document matrix (let's name it as D) is a document vector, with one column for every term in the entire corpus of documents. The matrix is sparse as not all document might contain a term. The value in each cell of the matrix is the term frequency.

example:
docid      term1      term2     term3     term4                                term n
d1            2             1            0              0                                    3
d2            0             2            3              4                                    1
d3            1             0            4              2                                    0
.
.

The transpose of the same Term Document Matrix (DT) will look as follows

docid      d1     d2        d3  .............. dn
term1       2      0          1 
term2       1      2          0
term3       0      3          4
.
.

We can create a Similarity Matrix (S) by multiplying D with DT { e.g. S = D * DT}
The structure of Similarity matrix will be as follows

docid   d1       d2        d3 ............. dn
d1       x11     x12      x13             x1n
d2       x21     x22      x23             x2n
d3       x31     x32      x33             x3n
.
.
dn        xn1    xn2      xn3               xnn

where Xmn = SUM Product of all term frequencies of docids dm and dn
Intuitively higher the value of Xmn, the more similar are the documents with doc ids dm and dn.

Coming back to our original problem, find which to documents are most similar. 
Simply look into the Similarity matrix and find our the row, col of the highest value in the matrix. 

The Serving Leader

"The Serving Leader" by Ken Jennings and John Stahl-Wert was my weekend reading. The book talks about five actions that can transform teams, business and community. My key takeaways from the book are

1. Serving leaders run to great purpose by holding out in front of their team a "reason why" that is so big that it requires and motivates everybody's best efforts
2. They qualify to be first by putting other people first
3. They raise the bar of expectation by being highly selective in choice of team leaders and by establishing high standards of performance 
4. They teach serving leader principles and practices and remove obstacle to performance. These actions multiply the serving leader's impact by educating and activating tier after tier of leadership
5. They build on strength by arranging each person in the team to contribute what he or she is best at. This improves everyone's performance and solidifies teams by aligning the strengths of many people

Some of the thoughts were counter intuitive such as "focus over strength over addressing weaknesses". Yet the argument that "it is foolish to pour all our energy into turning weaknesses to serviceable mediocrity" - makes profound sense. 

Overall a good read and fodder for introspection.