“Why are Function Points useful?”
Function Points measure software development costs in terms of the output delivered to the user. This provides an objective, comparable analysis of productivity, velocity and quality across teams and across market sectors, giving assurance to business users that they are getting value for money from the development team. Function Point size facilitates more accurate estimating, predictability and control. Function Points are measures of efficiency and should not be regarded as measures of effectiveness. Functional size measurement does not equate to a measure of value delivered.
“Function Points are not measures of value.”
Correct. They are measures of business functionality. However, used in the context of an effective, value-focused Requirements Management process they are key components of the value delivered by software. They are in fact the component of value for which the software developer is responsible. Ensuring the functionality is aligned to business need is the joint responsibility of the business user and the development team.
Which matters most – effectiveness or efficiency?
In terms of the Agile Manifesto, we might answer this as
“Effectiveness over efficiency”
Delivery of value must be the key driver of behaviour. This is not to say, however, that using money and resources efficiently is not a significant component of professional software delivery. Whether Agile or otherwise, good process discipline, appropriate documentation, feedback loops and integrated learning practices should all be used to create a virtuous spiral of improvement.
“Contracts based on Function Points incentivise dysfunctional behaviour.”
Any measure used in isolation from an integrated Lean value stream is likely to drive dysfunctional behaviour, and function points are no exception. If functionality is measured/rewarded, then lots of functionality is what you will get. If change requests are measured/rewarded, there will be lots of change requests. To get value, quantify and measure value. If functionality is a component of value, measure it.
“Outputs are not outcomes.”
There is much confusion over the use of these terms. For the purposes of contracting or performance measurement, it is best to work to specific, measurable business outcomes (eg “increase competitiveness” = “increase market share by x% over y=years”) or defined commodity outputs, such as functionality.
“What is a function point?”
In COSMIC, a function point is one data movement.
“Function Point measurement is a complicated and wasteful activity.”
Older methods of functional size measurement struggle to cope with modern software methods. This gives rise to arcane disputes and differences of interpretation which limit the value of the method as a performance benchmarking tool. However, modern functional size methods – COSMIC – address many of these issues. COSMIC is simple to understand and use for both business users and developers, and provides a common language for discussing and managing requirements, estimates, scope and costs.
“Why not use Story Points?”
Story Points are really a slightly more sophisticated method of measuring input, like Lines of Code. They are one team’s view of its own capability and rate of delivery, measuring time and effort consumed by the team rather than the size of the user’s functional requirements. Because they are not standardised measures, they cannot easily be used to compare or benchmark the performance of different teams, projects or suppliers – they are akin to medieval measures such as the “span”, which varied according to the size of the hand measuring it.