When software estimation is done in most companies, I have seen that developers mostly apply a single experimental number to productivity for all the activities related to development. This approach is inherently faulty in nature. Developers are humans and have varying levels of skill sets and productivity quotients. Resource estimation is an important area of consideration in the software estimation process as it is directly linked to effort estimation. By treating all individuals as one in estimating effort and hence productivity in a linear fashion, would result in producing faulty estimates.
Very well pointed out in the book by Murali Chemuturi, in the present scenario of software effort estimation procedures, productivity and capacity are often confused; productivity is used loosely where capacity should be used. He points out how using a single productivity quotient to all activities in software development creates inaccurate estimates and is an incorrect approach.
The figures of productivity such as person-hours/function point, formulas derived out of various estimation models (based on certain factors) are normally expressed to calculate productivity values. The issue is that such productivity calculation techniques associate all the activities associated with software development together into a single scale. Thus user stories definition, requirement analysis, UX designing, coding, code review, testing, integration etc are all clumped together in single measure.
However my basic question here is that each set of these activities are unique and require unique skill sets and tools required for execution. How can they be lumped together in a single measure when it comes to productivity for effort estimation?
Estimating all activities together with a common productivity quotient can only provide estimates which are inaccurate and non specific. This would result in faulty procedures of software estimation.
Correct Approach for Effort Estimation
Every activity in the software development process is unique and should be treated uniquely. Productivity associated with each activity should be measured independently as an Implementation type. By calculating effort for each action/activity separately, the estimates for each unique activity will come out to be more accurate. Hence requirement analysis, costing, testing, integration, etc and the sub activities will be estimated uniquely depending on skill level required for each. The time and budget would also be estimated more accurately depending on the effort as per productivity.
But the greatest benefit which I see in this approach is correct target setting when work is allocated to developers. Depending on the activity type, skills and productivity requirements, each category of of the job can be analyzed in a clear perspective. The presence or absence of such skills, deployment of available skills as per project requirement, rescheduling activities and better variance analysis for nurturing process improvements etc can be done.
When it comes to productivity definition, there are two components –effort and skill. A developer can be superior, medium or poor skilled while he/she may apply superior, medium or poor effort in his work; A poor skilled worker applying superior effort stand at the same level as a high skilled worker applying poor effort. The productivity definition in the organization should consider these factors to calculate average level of productivity and use it as a measure to estimate effort and hence time for delivering the project. The time to complete a particular project can thus be estimated based on allocation of these average resources (average productivity), however if superior resources or poor resources are allocated (mixed skill and effort combination), the estimates would change. The project manger’s role in such a scenario becomes quite profound with respect to resource allocation (as per required effort and skill matrix) and in ensuring that all the team members put the minimal of the average effort so that required deadlines with respect to estimated time is met.
Procedures to Determine Productivity
Industry can use data from earlier completed projects to determine a statistical mean/average to compute productivity calculation for effort estimation. However extreme values arising out of unexpected situations can affect the calculation.
Timesheets should be used not only to determine the attendance and hence payroll activities, but data from it should be channelized to calculate productivity by assessing time spent and project contribution of the developers over number of projects.
As we understand now, correct effort estimation in software development is a function of how well the productivity matrix is formulated and computed for a specific project. As I have mentioned in my earlier posts, the accuracy of estimation depends on detailed analysis and breakup of requirements into set of user stories and user actions AND well developed productivity matrix with correct combination of skill and effort for computing productivity and calculating the estimates for effort.
“Concerns With Productivity.” Software Estimation Best Practices, Tools & Techniques: A Complete Guide for Software Project Estimators. J. Ross Publishing, 2009. 137, 140, 141, 147.