The estimating project time game

gistfile1.txt

## Mechanics of the estimation

- Divide the project in phases, each within its deliverable.
- Ask the people in the meeting what is the estimation of hours per each phase.
- Get the average of the _n_ hours on each vote

           n
mu = 1/n (∑   x_i)
           i=1

That is the most basic calculation, although it has some caveats:

- It is not clear wether the estimations in amount of hours rely on how many persons
- It does not consider communication overhead (see https://en.wikipedia.org/wiki/Brooks%27s_law ,
  https://gigamonkeys.wordpress.com/2007/05/29/brooks-law-intercommunication/)
- It does not calculate the meetings held by the team or any other intensive communication.
- It does not contemplate the urgency of the project. Understand this as _how many hours 
  in a raw should N resources allocate during a I interval?_
  The more you push the acelerator, more hours in a raw _in average_ you spend to finish it
  the quicker. This is out of the scope here yet, tho it would be good to have this in the equation,
  as a coefficient.

## Trying to solve the problem of the estimation

Generally speaking, when someone estimate hours of a project, it does relying on previous
experiences. Each of those experiences can vary the team sizes and other hidden factors
such as communication channels and timezone differences.

For setting a more generic estimation, we set the concept of the super-worker, which is
this massive employee that does all those hours. This is m = 1, where m is the amount of
persons in the project.

By the Brooks law, the number of pairwise communications is:

(m(m-1))/2

Each channel must have a time spent in order to set a proper overhead over each hour.
This is a bit tricky as we don't have facts/labels yet on this to calculate proper coefficients.
An approximate way to calculate the overhead of each "message" is by using Hockney's
linear formula (http://ceng.usc.edu/techreports/1995/Hwang%20CENG%2095-14.pdf):

t_0 + f / r_

t_0 is latency
f is the message size
and r_ is the bandwith 

This is respecting machines, although I didn't find anything closer in the field to calculate
this in formula. The above seems pretty coherent, but still need a tweak.

By f (message size) it can be considered on how much the conversation do we need
to allocate.

t_0 the latency is the time spent by others during your talk.

The latency of all the people in an our won't be lineal, as the amount of
people in the project increases, the receptors will increase as:


𝛟 = duration of the standups in hours. 15 minutes, .25 as it is scaled in hours.
𝛗 = standup time consumed

𝛗 = (m * 𝛟) 


r_ is the bandwith which in our case will be how much time _per hour_ at maximum I do want
to dedicate to the project. And using the above formula we plug in our threshold:

- The project is 12 weeks long and I want to spend 3 standups/per week for all the team of .25 hours.
- The project not necessarily covers the full journal, meetings can have daily basis, although
  the project not. This is important as you set the theshold based on a total. You can assume
  full time projects as 8*5*12=480 hours one man power. In this case we discrimate aribitrarly this.
- A weekly meeting deeper, but calculated straight bellow.

Why we want to calculate the stand ups apart? Because standups generally are trigger of additional
conversations in channels or direct messages. So, 

(weeks * dows * 𝛗) / hourProj  = 12 * 3 * (m * 0.25) / hoursProj = (9 * m) / hoursProj 

So we have:

( wds * m ) / hourProj = % of time of standups of the project

with 10 and 20 on a 200 hours project:

( 9 * m ) / 200 = 0.45 and 0.9

So we'll be way short by estimating 200 hours for a 10 ppl team on this case!


And the thing is, we are going to add at least 1 pair communication burst of 1 minute after
each standup. That will be:
                
                 ^
(m(m-1)/2) * 0.016

0.72 with 10 ppl (That's a lot! 1 hour of communication after the standup even with 1 minute,
so we can expect much more).
20 hits an amount of 3.04. Clearly seems to be rough. Brooks was right ;)

M =minute scaled in hours .016

( wds * m ) +  (m(m-1)/2) * M  / hourProj 


We calculate 1 minute as the Pairwise communication can be unpredictable, so we calculate
the worst escenario where everyone speaks with everyone but during a short time.



The above calculation indeed, will return the overhead over your threshold. What is this threshold
value? That's the big question.

We can know the amount to needed standups + over communication for m people by:

( wds * m ) +  (m(m-1)/2) * M

within that, you can set your threshold in p-value of .15 (15%) and clear this out
by increasing hoursProject:

0.15 = ( wds * m ) +  (m(m-1)/2) * M / hourProj
0.15 = ( 9 * 10 ) + 0.72 / hourProj
hourProj = ( 9 * 10 ) + 0.72 / 0.15 

606 hours of project minimum.

So your threshold will be the scaled proportion of meetings per hour in the project:

hourProj / ( wds * m ) +  (m(m-1)/2) * M
( 9 * 10 ) + 0.72 / 606  = 0.15~

0.15 meetings by hour

As you see the post standup comm seems not to be an issue, although it increases 
drastically in magnitude. Also, you may want to enforce team communication, so the
1 minute arbitrary set can be increased, as the amount of standups.

So now:

( wds * m ) +  (m(m-1)/2) * M 
---                           = this should be overhead 𝝈 
0.15


This calculation is not useful when estimating, so it is barely considered at that point. 
However is important to model the dataset, as we can see how bad we did by under/overestimating
communication problems.

We also consider the meetings in the formula. 

           n
𝝒 = 1/n (∑  x_i)
           i=1
           
             m
𝝝 = (𝝒*𝝈) + (∑ d*j)

n is votes in hours
𝝒 is the average of the votes, so it's our value
d is the duration of the project in weeks
j is the amount of meetings per week
m is the amount of ppl in the project
𝝈 is a coefficient of overhead, which must be something above
  1, as the mean of the est hours is 1.

Being stated, you need to summarize all the meetings during the project per each
employee.