# Using function points as a metric for the velocity of a Scrum team?

I came across the idea of using function points as a metric for the velocity of a Scrum team. I saw it in a team and I found two articles mentioning a link between estimates and function points (http://www.ifpug.org/ISMA5-2010/Amol%20Keote-FunctionPointsAndAgile-Hand-in-Hand.pdf and http://www.cosmicon.com/portal/public/FromStoryPointsToCOSMIC.pdf).

I am not sure how this can work, because if I understand it correctly, function points measure the value of a feature (e.g. from the users perspective) whereas the velocity measures the effort of finished features. And in my view there's no direct connection between these two.

To put it another way: If you have (let's say) a stable Scrum Team which works 2 week Sprints, the number of functions points they deliver per Sprint should vary (possible wildly), which would render a velocity based on function points quite meaningless (e.g. for planning purposes)...

Am I missing something here?

• If gbjbaanb's answer is factual, then your statement of "function points measure the value of a feature" is incorrect. Feb 4, 2014 at 15:31
• Indeed. I'm still not sure though. Wikipedia states "A function point is a unit of measurement to express the amount of business functionality an information system (as a product) provides to a user" which led me to believe it is a measure of value... But maybe I am just reading it wrong. I mean: a "register" and a "login" function could have the same measure from a business perspective and totally different measures from an effort perspective, no? Feb 4, 2014 at 16:05
• @MetaFight It depends how you define "value". Value to the business in this case refers to the functionality of each component as you disassemble the problem; The value of a feature here describes how much of the original problem you can deliver - delivering more of the thing makes it more valuable after all. Feb 4, 2014 at 16:32

Function Points are a structured way to split a large task into many smaller ones.

Function Point Analysis was developed first by Allan J. Albrecht in the mid 1970s. It was an attempt to overcome difficulties associated with lines of code as a measure of software size, and to assist in developing a mechanism to predict effort associated with software development.

Function Point Analysis is a structured technique of classifying components of a system. It is a method to break systems into smaller components, so they can be better understood and analyzed. It provides a structured technique for problem solving.

Mind you, that site also says

Function Point Analysis should be performed by trained and experienced personnel.

so don't try this at home kids!

(or in practical terms - stick with making up rough sizes of your tasks in a "good enough" way, and keep on producing software without getting bogged down with the bureaucracy of a heavyweight process that might sound like a great idea but ultimately won't help you do anything better)

• Thx for the link. I was basing my question on this intro from the Wikipedia page for function points: "A function point is a unit of measurement to express the amount of business functionality an information system (as a product) provides to a user." It reads to me like they talking about value for the user/business. But this could be where I'm in error... Feb 4, 2014 at 16:08
• I just read the article you provided. From this: "Since Function Points measures systems from a functional perspective they are independent of technology. Regardless of language, development method, or hardware platform used, the number of function points for a system will remain constant." This is "value", right? The effort would vary across different technologies and not even linearly (function "a" could be easy in "C++" and hard in "Java", whereas function "b" could be easy in "Java" and hard in "C++") Feb 4, 2014 at 16:13
• My original post said bad things about wikipedia, but its not fair. What is fair is that you should never rely on what some random put on that site. Verify it! As for FPs, its all about splitting the problem up into components, not technology development time. Those components are what's counted, and they should end up small enough to be used within an agile environment as a "cost" of creating them. The difficulty of each is incidental - you don't know how hard something is to do as the FPs are not describing the problem in terms of technology but of functionality. Feb 4, 2014 at 16:32
• Ok. I understand that now. If your answer includes the last sentence of your comment above, I can accept it as "the answer". Feb 4, 2014 at 16:53