Function Points and Agile

I participated in an interesting conversation on Function Points and Agile with members of the software development group at a federal agency recently.  We, the DCG team, were explaining how we would start the process of measuring how much value they are delivering from software development by measuring how much functionality they are delivering in function points.  For an organization with immature metrics and, perhaps, lack of user trust, this starting point takes the question of productivity off of the table to allow us to move on to end user value delivery

All of the participants in the meeting quickly recognized the value of having a standard metric, function points, to measure the size of the functionality being delivered (and with SNAP – the non-functional size too) but I could see on their faces the sort of trusting disbelief that might be associated with my pulling a rabbit out of my bag.   Some of the participants in the meeting were not familiar with function points and asked for a quick, five minute explanation.  I get asked this a lot so here it is (before I get inundated with corrections – I know - this is an over-simplification):

Imagine a software application and draw an imaginary boundary around it in your mind to include all its functionality but not the functionality of other applications that it communicates with or draws information from.  Now consider the diagram below.

Function Points and Agile

From a user perspective, looking at the application from outside the application boundary, I can interact with the application in three ways, called transaction functions: external inputs (EIs), external outputs (Eos) and external inquiries (same as input and output but with no change of data or state - EQs).  From within the application, I can access data in two places – inside the application boundary or outside the application boundary.  My interactions with these files are the two types of data functions: internal logical files (ILFs) where data is stored within the application boundary and external interface files (EIFs) where data is stored outside our application boundary. 

Most of you will be able to easily imagine that these five types of user interaction with our application can be more or less complex.  If I want to produce a function point count, the next step is to consider the first of the transactions that the user wishes to perform on the application (as defined in the requirements, user stories or whatever) and to identify how many of each of the five function types is involved in the transaction and how complex that involvement is (low, average or high).  Predetermined rules govern the weights that apply to each function type based on the complexity of the function in this transaction.  With all this information gathered, we can calculate the number of function points using the simple table shown below.

Function Point Counting Weights

Type

 

Low

Avg

High

Total

EI

 

__ x 3 +

__ x 4 +

__ x 6 =

___

EO

 

__ x 4 +

__ x 5 +

__ x 7 =

___

EQ

 

__ x 3 +

__ x 4 +

__ x 6 =

___

ILF

 

__ x 7 +

__ x10 +

__ x15 =

___

EIF

 

__ x 5 +

__ x 7 +

__ x10 =

___

 

 

 

 

Total

____

 

One of the participants offered a very perceptive observation, “Isn’t this a lot of work for every user story in Agile?”  It could be.  In practice though, by the time a user story is defined and understood, the software problem has been decomposed to the point where identifying the FPA functions and complexities is fairly simple.  That said, we don’t recommend this for all agile team members.  Story points work fine for most agile teams.  Where function points (and SNAP) can and must be used for Agile is where there is a need to aggregate the delivered functionality (and non-functional elements) into higher level metrics  for reporting to management.  This level of function point analysis is often better done by a separate, central team rather than the agile team members themselves.

 

Written by Michael D. Harris at 15:17
Categories :

3 Comments :

Hala Osman said...
according to many publications in agile measurements and using traditional metrics such as FP in agile projects, also depends on my research on agile measurements with FP through some real case studies. there are some problems emerged when used FP in agile environments. for example these are : 1. User story express customer’s needs that involve more detailed in developing the features, risks, complexity and all quality and technical requirements. In addition, story point estimate complexity of the story, while Function point doesn’t covers Non functional requirements. User stories express non –functional requirements but don’t work well for it. So; it not simple to try breakdown story into smaller tasks to extract function point’ factors from it. That causes the calculation of FP to be imprecise and incomplete. 2. Calculation of function point from a story is more difficult to apply, since: A. It requires detailed analysis about the user story that it’s not available on agile project due to the nature of documentation in this field. Also; there is a template that most scrum master follow to breakdown stories into smaller tasks, but this general template is not appropriate for all tasks. etc..
June 10, 2017 09:11
Anjali Mogre said...
All agile projects says function points are not for agile. Story point is good enough, however there is no definition of standard story point definition. Any comparison or organizational level database can not be prepared using the story point because the definitions are not standard. I told them to use the definition of function point while call it a story point - but still it does not gel with Agile. Projects feel productivity measurement is not their responsibility, some one outside group should do it. any example where Agile projects have used function points for estimation.
February 17, 2017 07:00
Anjali Mogre said...
All agile projects says function points are not for agile. Story point is good enough, however there is no definition of standard story point definition. Any comparison or organizational level database can not be prepared using the story point because the definitions are not standard. I told them to use the definition of function point while call it a story point - but still it does not gel with Agile. Projects feel productivity measurement is not their responsibility, some one outside group should do it. any example where Agile projects have used function points for estimation.
February 17, 2017 07:00

Comment

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG President

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!