There is nothing wrong with making decision based on your intuition. But it never hurts to do a little bit of math. I find the following 4 examples very useful;

**Example 1: The Communication Explosion **

Fred Brooks (Man Mythical Month) is famous for his law “*adding manpower to a late software project makes it later*“. The reason for this is the added burden of communication which leads to a productivity decrease. This is made up of 2 parts; training and communication between team members. Brooks gives away a simple formula to calculate the number of potential interfaces: **x = n(n-1)/2**.

So if you have If you have n members in your team, there are x interfaces across which there may be communication. Are you sure you want N+1?

**Example 2: The Calculated Risk **

You have a list with 15 risks (n), each one has a low probability of hitting you; say 10% (p). The chance (c) that at least one of them will hit you is nearly 80%. That is, one minus the 15th power of 0.90. That’s worth talking about during a project meeting. In a formula: **c = 1-(1-p)^n**

That’s worth talking about.

**Example 3: RISKOLOGY **

Tom deMarco and Timothy Lister wrote a great book called Waltzing with Bears, managing risk on software projects. In that book they introduce RISKOLOGY. RISKOLOGY is a free simulator which runs under Excel. The program can tell you how wide the window needs to be in order to cover all the uncontrollable risks of your project. It takes into account 5 core risks of any software project;

– Errors in original sizing

– Effect of employee turnover

– Requirements function growth

– Failure to reach consensus (Fatal)

– Effect of productivity variance

All it needs is 1 input: you most optimistic delivery date. This should be easy 🙂

**Example 4: The Fault Feedback Ratio **

The Fault Feedback Ratio (FFR) – the % of fixes that actually feed another bug into the system. Jerry Weinberg (Perfect Software and Other Illusions about testing) writes; “*The estimated FFR is 25%, with 1 bug introduced in every 4 bugs fixed, but in my experience this is rather low.*”

So if we have 4 weeks to deal with 60 bugs…..and we take into account that 1/4 of those fixes (15) and have to be fixed again…so we need another week to deal with 15 bugs and we still have 4 bugs which need to be fixed….hmm…this information will surely help future test planning.

Recently I read a great quote on math by S. Gudder;

“*The essence of mathematics is not to make simple things complicated, but to make complicated things simple*.”

Pingback: The 60-30-10 principle | Ronald's Blog