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.
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:
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.