Earlier this week, I conducted a simple and what I believe, was an engaging and effective workshop on estimation and ROM sizing - a critical aspect of proposing software projects. The audience was a group of project managers. 
 
Any such invite on the calendar asking for participation in a project management activity is viewed with some skepticism. ‘One more meeting…” is the thought that must have run through the minds of those that were invited to the session. 

Regardless, they all showed up. The end result was in my opinion a very engaging session. They all participated. We all learnt from the session. 
 
This post is to share some of the learnings from the session. 
What did we set out to do - Essentially, I wanted to communicate the power of separating “Effort' estimation, from 'Elapsed Time' computation; while further separating both of those from ‘Resourcing'.  

My sole focus was to engage the team in a hands-on activity that would convey the reality around the wide variance of software estimates even when conducted by different individuals in the same room against the same spec. It would tell us us what clients experience when they see proposals created by different members in the same group. 
 
With the exercise around "Effort" estimation completed, my intent was to use their estimate and have them perform an "Elapsed Time" computation. After those two steps were completed, we went on to put together a "Resourcing Plan" with the right skills and corresponding capacity.
 
Before we got started, we needed a simple but complete business need. We just picked a sample requirement for this purpose. 
 
Outputs from the exercise: 
There were 15 people in the workshop.  We received 15 estimates. In any such exercise, there is bound to be a spread. All that we can strive for is narrow variance. The data gathered is charted below for your reference. The data, even being a small sample, when charted followed a near-normal distribution. That is a good sign. However, the data was also skewed to the left of center, indicating the general bias to estimate lower.  

Using these estimates we then moved on to computing Elapsed Time.  
But before we did this, we needed to set some contextual parameters: 
A) we adopted the AGILE process model for this task 
B) we time-locked the Sprints at 2 calendar weeks
C) we capacity-locked the Sprints to 80 capacity hours  
D) this left 'Scope' to be the variable element

To get a little more room to compute the Elapsed Time computation, we asked each participant to take their estimates and multiply it by 10. 

For the example shown below, the PM had his effort at 410 hours.  

This computation indicates a 12 calendar week timeline. 

Now for the important thing... note that till now, we haven’t spoken about resources at all. And thats for a reason. 

The resource staffing matrix or the ’staffing plan’ as it is called, is not relevant till this point. 

The important and critical learning here is that the Effort is the effort. It has nothing to do with elapsed time or the staffing plan. There may be some influencers such as team experience levels, productivity, tech stack, architecture construct, programming environment, tools etc., but Effort remains the effort. 

Like wise the delivery model has little or nothing to do with Effort. The work remains the same. Whether we deliver via iterations or sprints, Effort does not change. If work breakdown changes, then due to granularity, effort may appear to change but it really hasn’t. 

Building out a resource model involved composing a team to have a total capacity of 80 hours per Sprint - aka - over a 2 calendar-week period (remember earlier on, that is the number we locked our Sprints to - 2 calendar weeks).

These 3 steps provide a reliable, repeatable method to arriving at Effort, Elapsed Time and the Staffing Plan.

Until next time…
CP Jois