Software Projects: Better Estimation and Control

Almost everybody these days sizes software story points. But what is a story point? To every agile team, it means something different.

For a self-governing agile team the story point, is OK, it’s principally about effort and time spent than a measurement of delivered functionality.  Tasks that don’t actually deliver functionality are also measured in SPs.

The job of a software project manager is far more than just re-presenting a burn-down chart, he needs something more user-oriented, and more universal.  Appropriate metrics are essential on a well managed project.  SP’s are inadequate for PM’s except for the estimation and measurement within the context of a single agile team.

As it happens, there is a good technique for software project estimation and measurement.  Not many people are aware of it, nor how to use it effectively.  B.A.s have a great opportunity to introduce this and raise the certainty of software projects.

Before diving in on the answer, let us take another look at the wider context.

1. Budgets for software changes are typically assigned at the project level, not for a stream of work (which is how Agile teams are set up). Agile teams’ estimates are based on story points, which can vary wildly from team to team and organisation to organisation.
2. Senior IT management expect PMs to give reliable delivery dates, firm cost estimates based on expected functionality – all up front. Story points are not a suitable metric for development contracts.
3. Agile practices are very effective at producing software – the customer usually gets what they want, in due course. However, Agile teams struggle with whole project estimation.
4. Agile teams self-manage using (arbitrary) story points and a finite capacity to deliver work each sprint. However, senior IT management cannot budget, measure or report based on story points as a business metric.

Part way through my career I learned about a technique from the 1970’s called Function Point Analysis (FPA).  I was shown how, when used thoughtfully, this technique can bring incredible predictability to software projects.  FPA is the process of counting Function Points (FP), a measure of software size from the user’s perspective.  FP’s are the only ISO standard approved measurement of software and are even suitable for development contracts.

So why have so few people heard of FP’s?  There are likely to be several reasons, but mostly, they are considered old fashioned and they are hard to count.  Counting function points has always been a manual process.  Around 20 years after the initial methodology was invented, an updated revision was published that addresses many of the criticisms of the orginal method.  Cosmic Functional Sizing (cosmic-sizing.org) is the latest incarnation of this ISO standard.  Cosmic, brings the technique up to date for modern software architectures and is a principle based method.

Function points can be counted even before the software is written,  they are far more appropriate than story points or lines of code because they focus on the measurement of functionality from a user’s perspective.

There is substantial data available on the statistics of past projects measured using function points, specifically the writings of Capers Jones and data available from ISBSG.

Function Points are about size measurement, but they can also be used for estimating and managing other aspects of your software project:

Size: FPs to be developed or changed as part of the  project.

Scope change: as above.

Quality:  defect potentials per FP and defects found per FP are two examples.

Schedule estimates: number of months needed to delivery a given number of FPs,

Schedule adherence: adherence to an expected delivery rate of FPs per month.

Resources allocation: Staffing and costs needed to deliver an amount of FPs

Earned value delivered:  FPs are a direct indication of useful user functionality.

Vendor estimate validation: compare proposals against typical industry costs per FP

For the last ten years I have used function points on every software project, they have given me great insight, very quickly.  Most of these projects have involved Agile software delivery teams, and I have measured the FP’s alongside the story points.  This works just fine.  Story points are the primary metric for output and productivity within a scrum team and FP count is my primary metric at a vendor, project and even portfolio level.

Once I discovered how effective and valuable FP’s are to me as a PM, I was surprised that I had not come across them before.  It seems that so few people are aware of, or appreciate the value of them.  There are perhaps a few reasons for this:

1. FPs are considered old fashioned and irrelevant to modern techniques. This objection is no longer valid having been addressed by the latest generation of Functional Sizing Methods, Cosmic-sizing.org
2. Functional Sizing is considered to be hard to learn. Yes, I spent many months learning to become competent and certified in counting IFPUG FPs.  The  Cosmic method is considerably easier to learn.  And now with the automated counting tools doing the heavy lifting, there is less need to spend time learning the methodology.
3. Cost, you have to pay to obtain the IFPUG manuals. The Cosmic method is a free open-source project.
4. Counting function points takes time and businesses have neither the time nor inclination to allocate to the sizing activity. A false economy of course.  Nevertheless, there are tools now on the market that count FPs for you, from pre-existing code, see CastSoftware, or from user stories / requirements, see ScopeMaster.
5. There is little understanding of the potential co-existence of FP’s alongside story points. This is what I have practiced for the last ten years it works just fine.
6. Development vendors generally avoid quoting in FP’s. I believe that this may be because it would equip the purchaser with a metric to negotiate a lower price.

I highly recommend that you take some time to look into the free project cosmic-sizing.org.   Once you have the ability to count and use function points, you will feel like the one-eyed man in the land of the blind and eventually colleagues will turn to you for guidance.

Colin Hammond, M.Eng, MBCS, CFPS

Colin is an experienced IT project and portfolio manager.  He has worked for many well-known organisations across retail, financial and education sectors, mostly on software development projects.  

Colin is the author of ScopeMaster.com, a tool that helps improve the quality of software requirements and simultaneously measures functional size automatically from requirements text. 

colin@albiontech.com

www.scopemaster.com