Better software estimation

I wrote earlier about the importance of Software estimation procedure. I would like to highlight the latest research on software estimation and share few tips in this post. Jorgensen, M. published an interesting article titled

"What We Do and Don't Know about Software Development Effort Estimation" in IEEE Software, March-April 2014 issue, where he reviewed the software effort estimation and suggested  the following guidelines

Which one is larger? Relative estimation can introduce biases

"

1. Develop and use simple estimation models tailored to local contexts in combination with expert estimation.
2. Use historical estimation error to set minimum-maximum effort intervals.
3. Avoid exposure to misleading and irrelevant estimation information.
4. Use checklists tailored to own organization.
5. Use structured, group-based estimation processes where independence of estimates are assured.
6. Avoid early estimates based on highly incomplete information."

Most of us resort to expert judgment as the method for estimation. In a related research titled "Relative Estimation of Software Development Effort: It Matters with What and How You Compare" (pay walled), he identified the common pitfalls in relative estimation and provided the following guidance.

"

1. Make Comparisons to Similar Projects and Use Work Hours
2. Attend to Unique Properties of the Reference Project
3. Attend to Estimation Sequences
4. Avoid Using Small User Stories as References
5. Attend to Request Formats
6. Use Combinations of Independent Estimates"

Going through the above checklists can help you identify areas of improvement.  Make a beginning by reviewing  your recent experience of project estimation against the above guidelines and share your experiences/challenges.

Evidence driven Project Management competency improvement

In Large and medium organizations, the competency improvement needs are identified using a top down approach.  This approach  helps in taking the organization to the next set of competencies, based on the process/product/technology road maps and assessment of the current competencies.  The needs so identified  are addressed  through the competency improvement of the individual employee, while addressing his/her career preferences. While this is usually helpful as a first step and results in a set of trainings, this  may not help address the deficiencies fully.  I take project management as an example and present an approach for assessing the competency gaps and tailoring an improvement solution that can be driven by Project Management Office (PMO) or equivalent role.


As we know when a  software projects is challenged, root causes are identified and a solution to address the same is implemented. This is more likely to be adhoc and may fail to address  deficiencies holistically. PMOs can  follow the structured approach below as a better alternative.

1) In the recent review period( last month/quarter/year), identify the challenges faced  by each project,  assigning one or more of  the 22  anti patterns (examples: Detailitis plan, Road to Nowhere, Micro management) compiled and  analysed by Pedro Silva et.al, "Software Project Management Learning from Our Mistakes", IEEE Software, May/June 2015 pp 40-43.  This could be tailored as appropriate.

2) Perform a statistical analysis on the anti patterns to identify the top  anti patterns.

3) Identify the impacted roles and root causes.

4) Based on the above, identify the solution from one or more of the suggested solution types (process/role/technology/training).

5) Work with internal/external solution providers to implement the corrective actions spanning process redesign/training/coaching  etc.

6) Repeat the above steps to see whether  the solution  has yielded results.

In my extensive experience in industry, the first and last steps are  not given due importance with the result that the competency improvement remains weak at best. Do you agree? Share your views.

Compounded Annual Growth Rate of Software

Last week, I attended Software Experts Summit 2014 organized by IEEE Software in Bangalore. Having seen the videos of the previous summit, I thought it is worth investing to understand the advances in Software.  There were several speakers from India and the world who covered various topics like Analytics, Big data, Need for Innovation and Speed, Architecture of Watson. In this blog post I would like to share with you a new metric that I learned. It is called Compounded Annual Growth Rate(CAGR) and was coined by Michiel van Genuchten and Les Hatton, based on the analysis of various software industry reports over the past four years.

Credit:Adapted from Pictofigo , Commons

IEEE Software is a bimonthly publication of IEEE Computer Society. Apart from several articles from academics, this also has a column called  Impact, which features industry reports  highlighting the software  challenges with focus on software growth as reflected in two metrics, namely the Lines of code(LOC) and volume of  units sold. In 2012, based on 10 data points such as Tokyo railway system, Mars Discovery, Higgs Boson discovery, oil and gas simulation, Michiel and Les came up with a "Compounded Annual Growth rate"(CAGR) metric. Based on the LOC metrics provided for the early phase of the application and the recent release, the team computed the CAGR. Median CAGR was found to be 16%. In July 2013 magazine article (paywalled), they recomputed the metric including the additional data from application domains such as Oracle, Airbus, Mars lander. The metric was determined as 17%.

The metric was found to be useful for  determining the hardware platforms of the future to support the future software. It can also be used to determine the health of the organisation as the metric will be low, when the organisation is dealing with bug fixes or addressing technical debt rather than new feature development. So far the metric has proved to be relevant irrespective of the complexity of the application and domain.

Have you tried using this metric or any other innovative metrics? Look forward to hearing from you.