What is the difference between story points and function points? Both function and story points are a measure of size, but they are derived by different means. The big difference is that story points are a measure of size determined by the team, while function points are a measure of size based on a standard set of rules[1]. There is not a perfect analogy, but one that I use is that the difference is like measuring the distance between New York and Chicago in miles or the number of rests stops I’d need if I was driving. Both are predictable, however only one is understandable outside of my team.
Function points (see What is a function point?) are a measure of the functionality delivered by the project or application. All of the different types of function points are based on a set of rules that can be applied consistently by any trained practitioner. Size is generally reflective of a count of a set of components (External Inputs, External Outputs, External Inquires, Internal Logical Files and External Interface Files). The size of each component is judged based on attributes like fields, files and groups of data.
Story points are based on the team’s perception of the size of the work. The determination of size is based on level of understanding, how complex and how much work is required compared to other units of work. For example, one team might feel that developing a new service to insert customer records in a database is complex and large, while another team might perceive the same piece of work as less difficult. Scales for story points vary, however the two most common are the Fibonacci sequence and Cohn’s numbers.
Both function points and story points can be used to gauge how much work can be accomplished in an iteration or release. The difference between the two sizes is generally who is involved in making that determination: the project team or an estimator. Another difference between the two measures of size can be seen in the how story points and function points can be used in organizational measurement programs. Simply put, since story points are a reflection of the perception of a specific team they can’t be used to compare performances across teams, nor can they but summed up to generate organizational metrics.
Story point and function points represent size. Story points are created by a specific team based on the team’s cumulative knowledge and biases. The result of developing story points is useful to help the team plan, but not useful outside of the team. Function points are a reflection of size based on a standard set of rules, rules not developed by the team therefore less intuitively understandable, but more useful at an organizational level. If the question then becomes, “Which measure of size should I use?” The answer, as always, is it depends on what you need the information for. If you are collecting organizational metrics, using parametric estimation or have dynamic team structures (common in matrix organizations) then function points make sense. If size is used by a team for its own use and the team structure fixed then story points can be very useful.
[1] There are several international function point standard including IFPUG, COSMIC and NESMA.
November 7, 2013 at 2:47 pm
Calibration could be tricky, but it would be interesting to see comparisons between FPs and SPs for a given team over time to see the difference between the objectively measured size and the teams perception of size. It would be particularly interesting to see the reasons behind any discrepancies.
November 7, 2013 at 8:26 pm
I suspect that the discrepancies would be driven by how team perceives the unit of work or by team changes. The study would be an interesting exercise
.
November 7, 2013 at 8:42 pm
That was poorly worded on my part…I’d be interested to see what factors caused the perceptions to diverge from the FP measurement (experience, communication, etc.).
November 7, 2013 at 9:46 pm
How can do the study?
November 8, 2013 at 1:30 am
Recorded planning poker sessions (assuming diverse team to study) would probably take care of discerning rationale for scores from team, particularly if paired with a facilitator primed to probe for “whys” without leading.
November 15, 2013 at 11:56 pm
[…] Story Points, are a representation of the size of a user story or any unit of work based on the collective understanding of the team that is being tasked to deliver the work. The use of story points provides a team with a consistent scale that helps team members communicate about their perception of size. […]
December 23, 2013 at 11:56 pm
[…] defined IFPUG Function Points as a measure of the functionality delivered by a project or application. We have also talked about […]
May 5, 2014 at 1:15 pm
[…] owner identifies, the team develops or reviews the size of each unit. I am a proponent of story points or quick and early function points for the sizing process. Both processes help teams drive out […]
June 2, 2014 at 11:56 pm
[…] points (vs function points) are relative measure based on the team’s perception of the size of the work. The determination […]
July 7, 2014 at 9:38 am
Actually there is a school of thought out there that you shouldn’t be trying to size pieces of work. In an Agile world you want to encourage teams to break Features down into the smallest sized Stories that have tangible Business Value. Then by sratistical analysis all stories will be of similar small size (within a bell curve of tollerance. So all one has to do is count stories. There is a good article here:
http://www.dontpanicitsolutions.com.au/lean-thinking/57-estimation-part-6-the-argument-for-story-counting
April 7, 2016 at 11:57 pm
[…] (for example, IFPUG Function Points) and a wide variety of physical (lines of code) and relative (story points) measures. In software development and maintenance, the functional software presents the whole […]
April 11, 2017 at 11:55 pm
[…] Measures in this category use the measurer’s perspective as a framework to assess size. Story points and tee shirt sizing are examples of relative size measures. This form of measurement makes that […]
December 30, 2017 at 1:09 am
It would add to your edge and improve your chances of profitable
as a result of availability of the different actions.
September 19, 2018 at 9:00 pm
[…] bij het agile werken. Dit is een thema waar ook veel over wordt geblogt, zie bijvoorbeeld deze, maar het verbaast me toch elke keer dat er een aantal hardnekkige misverstanden blijven bestaan […]