Buffer over Pad

 

When one of our ex-VPs suggested me to read THE GOAL and tried to explain me the importance of a schedule/project buffer rather than task buffer(read padding), I failed to understand the importance of it. This resulted in a fixed % padding for each micro task. The law of karma forced me to pay a price :) Let us not be over enthusiastic in reinventing the wheel every time or go by our presumptions of Project Management skills. The first lesson on Project Management I learnt is that it is an “Art which is Practiced”. Lets see what truly successful projects<writeup very soon> have adopted.

We will discuss here the scientific way of buffer management which has passed the field tests.

Chapter 17 : Buffering Plans for Uncertainity under Part IV : Scheduling of Agile Estimation and Planning by Mike Cohn (to buy, you may search it here) is more than sufficient to understand the what/why/how of buffering to kick start.

To give you a gist, insecurity breeds the tendency to PAD whereas open and professionalism culture breeds the tendency to scientifically buffer. And when you scientifically buffer you are not only securing DELIVERY but also wining the confidence of the stake holders and further making them part of the decision by clearly presenting the scientific methodology adopted. You need to be suggested for communication skills training if even after this your client or higher management is unhappy with the project plan. Such is the beauty of this scientific method. Further we need to understand that buffer is a requirement, so when it’s not required it’s not present or tends to zero. For eg. in a project of say a few stories spanning across a single iteration of a couple of weeks, who needs a buffer – each task can be detailed effectively considering all the risk factors.

The next paragraphs below put up the gist.

Go by the 50% & 90% estimate funda given by Mike Cohn. Meaning you give 2 estimates for each story. The first one is a very very optimistic one and the other one is a very leisurely one. To quantify it the first estimate tells us that the story will finish in this time with a 50% probability or in other words 7 out of 14 developers available can complete the story in less than or equal to this estimate. Apply the same principle to the 90% or the leisure buffer.

While we are giving the 50% probable estimate and moving on to calculate the 90% probable estimate, what needs to be noted is that more higher probability of finishing the story is making sure more and more risks are mitigated. This means for a particular story - “Create a screen to enter demographic information” could have an estimate of 5-9 story points in the 50-90 category, whereas another story “Create the login page” could have an estimate of 4-20 story points following the same analogy, since I feel there is a prominent risk that the part of the security architecture dealing with Authentication could need amendments, like the ready-made framework designed may not have been tested yet so I need more cushion here on the leisure estimate side.

You tend to lose your credibility with a pure 90% estimate and you tend to lose accountability with a pure 50% estimate. And don’t jump to conclusions, we are not going for a mean (50+90) / 2 :) The SRSS methodology is to be used to arrive at our required estimate. This estimate now is cushioned with a buffer.

One of the most important points mentioned by Mike Cohn is to is to openly declare(or unhide) the Project/Schedule buffer to all stake holders. In this regard, majority of managers or project leads miss out one of the most important stake holder of the Project that is the TEAM<writeup very soon> (specifically the ones who are sculpting out the software piece). The reason most of the time is either fear of misuse or mistrust or non-confidence on the maturity levels and many times a subtle hunger to project on-time delivery to the client and higher management but underachievement to his/her own TEAM. This behavior is not only unfavorable to the TEAM but directly affects the Quality of Delivery<writeup in near future>. This could further ignite non-transparency and violate the agile manifesto.