In a LinkedIn discussion, which originally prompted the writing of the previous post (Function Points Are Fantasy Points), we find Simon Harris comparing Function Points and Story Points, and offering this point of view:
Story Points are all 'Function Points' in philosophy if not detail.
When, we critique Function Points and happen to mention Story Points in the same context, it is frequent to receive the objection that Story Points are like Function Points. The similarity is only superficial. In this post we examine the differences.
Story Points are NOT an Absolute Metric
Often it is argued that Story Points cannot be used as reliable metrics; but this misses the point of Story Points (pardon the pun :-). Story Points estimates are derived through a modified Wideband Delphi process amongst all involved developers. There is consensus within the team about their significance in their particular context. Story Points become reliable in that particular situation, because in that context – as [COHN-2005] teaches – it is not the absolute values Story Points that count, but the ratios between them (more specifically: the ratios between the Story Point values attributed to the work items).
Story Points have a few drawbacks, primarily due to their abstract nature. Often, the “true size” of Story Points are debated, and can get teams off track, especially if they are new to this technique. The absolute size of a Story Point is irrelevant. What makes the technique work is the relative sizing of work items in terms of Story Point ratios. Story Points are just the numeric artefact used to be able to express such relativity. (Those ratios allow to monitor project progress in terms of velocity variation, during the projects due course; the ratios allow to forecast when the project will complete.)
Function Points have the pretense of being an absolute metric, with which you can compare project sizes indistinctly. 256 Function Points in my team represent the same amount of work as 256 Function Points in an unknown team, on the other side of the globe, using a different technology, solving a different problem, and engaging different people; but 257 Story Points in my team have no relationship with 257 Story Points of any other team. Function Points should even translate to specific number of lines of code, depending on the implementation language.
Story Points Reduce Risk
The Story Points as such are less interesting than either the way they are derived, and the way they are used. Story Points are assigned to work items through a Wide-band Delphi estimation process, and not by counting “countable” elements of the envisioned solution. The Wide-band Delphi method is a well known method based on expert opinion and group work. The technique has a long history and track record for software estimation, going back to the works of [BOEHM-1981]. The Wide-band Delphi estimation technique is a means of reducing uncertainty in the estimation, as highlighted by [CHARETTE-1989].
Function Points appear to be more objective, as they are about counting “countable” things. Unfortunately, the countability is overshadowed by the fact that the countable things are not known in detail, until the software is finally delivered. Function Points are inherently more loaded with risk, as they ignore more unknowns than what can be counted up-front.
Story Points Involve a Social Process
Function Point counting is “easy;” to the point that – as observed in the previous post – anybody can do it. It is like counting sheep in a field.
Story Points are derived through the group interaction of the Wide-band Delphi method. In particular, expert opinion is taken into account: the opinion of the developers who will ultimately program the solution. Not anybody can express the Story Point estimate: only experts are allowed to do it.
Since these experts are those that ultimately will perform the work, this has significant effects on developer morale. Developers will “buy-into” their own estimates, and feel more attached and committed to their implications.
Function Point estimates are imposed upon developers as an Act of God, which cannot be disputed because based on the “scientific” approach of “counting.” The psychological effect on developers morale is devastating, and the results will reflect such devastation.
Function Points are an artificial metric; Story Points represent expert opinion. There are other fields of human endeavour where professionalism is built almost exclusively on expert opinion (like medicine, law, etc.). It is a weak argument to sustain that the Story Point approach is “non professional” – unless one is ready to claim that professional programmers are not experts.
(As we mentioned in the Software Craftsmanship Management post, many are convinced that programmers are “scribes” that “just” have to transcribe requirements documents into code. Those that hold such opinions deserve to get the failed projects they foster.)
Story Point Estimation Galvanizes the Team
One fundamental difference between Function Point estimation and Story Point estimation is seen as early as when the project appraisal and approval is conducted. Traditional project management starts with scoping and sizing, in order to derive schedule, timing, resources, etc.. That is the very reason why traditional approaches need to estimate. Traditional approaches estimate to establish when a delivery is likely to happen, what resources will be needed, and the scope of the delivery.
Using Story Points is a kind of estimation; but the objective is different and emphasis is on other aspects rather than on the predictive capability. (At least, in the projects conducted by The Chronologist).
The emphasis is more on the sociological/psychological side of the estimating process rather than its predictive value. The purpose is to build a common understanding and shared vision of the undertaking. In doing so, all shareholders and project participant come to a common conviction about whether or not the project “can be done.” This mindset of confidence is critical in achieving hyper-productivity, and ultimately delivering what is needed. Done correctly, it will galvanize both the team as well as stake-holders.
(Note, just because we highlight the sociological and psychological aspects of Story Point estimation – because we are comparing to Function Points that lack these aspects – this does no way mean that Story Point estimation cannot be used when dealing with project investment appraisal. In fact it is one of the techniques developed by The Chronologist, especially in combination with the Incremental Funding Method. You can read more about this in [SMITE-2010].)
Story Point Estimation Maps the Territory
The shared vision created through the group process of Wide-band Delphi estimation maps out the territory that the team will have to cross. The visual information radiators used in Agile/Lean approaches are a representation of the territory. It creates a macroscopic check list of what the whole team believe is going to happen. It prepares the team for what is expected to come. The team will be better prepared and ready to react when the unexpected comes. Think of this as a pre-flight checklist: it is used to determine if the team is ready before the journey commences. Then it is used during the journey to discover if there are unexpected variations. It is a way to pre-empt risks.
Function Points, on the other hand, are just a numeric value. They presume to tell how hard it is to make the project happen; but they don’t contribute much else in terms of involving stakeholders and development team. They contribute even less in terms of risk management.
Conclusions
There are many more differences between Function Points and Story Points. The points :-) presented above, though, are representative enough to conclude that Function Points and Story Points are two completely different beasts.