Function Points


We are enjoying a bit of a holiday.  Yesterday I toured La Sagrada Familia in Barcelona. The basilica was started well over 100 years ago and is now planned to be completed in 2026.  I am struck by how persistent and motivating an idea can be.  While function points are not as old, they are equally as persistent and useful.  Please enjoy this throwback essay on function points: (more…)

Listen to the Software Process and Measurement Podcast

SPaMCAST 317 tackles a wide range of frequently asked questions, ranging from the possibility of an acceleration trap, the relevance of function points, whether teams have a peak loads and safe to fail experiments. Questions, answers and controversy!

We will also have the next installment of Kim Pries’s column, The Software Sensei! This week Kim discusses robust software.

The essay starts with “Agile Can Contribute to an Acceleration Trap”

I am often asked whether Agile techniques contribute to an acceleration trap in IT.  In an article in The Harvard Business Review, Bruch and Menges (April 2010) define an acceleration trap as the malaise that sets in as an organization fails prey to chronic overloading. It can be interpreted as laziness or recalcitrance, which then elicits even more pressure to perform, generating an even deeper malaise. The results of the pressure/malaise cycle are generally a poor working atmosphere and employee loss. Agile can contribute to an acceleration trap but only as a reflection of poor practices. Agile is often perceived to induce an acceleration trap in two manners: organizational change and delivery cadence.

Listen to the rest now

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change of on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 318 features our interview with Rob Cross.  Rob and I discussed his INFOQ article “How to Incorporate Data Analytics into Your Software Process.”  Rob provides ideas on how the theory of big data can be incorporated in to big action.

 

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST

Register Now

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

Listen to SPaMCAST 297 now!

SPaMCAST 297 features our essay on IPFUG Function Points. IFPUG Function Points are a measure of the functionality delivered by the project or application being counted based on a set of rules documented in the IFPUG Counting Practices Manual (CPM). The measure of delivered functionality is a proxy for size which can be used in estimating and measuring work. An analogy for function points is the measure of the number of square feet (or square meters) of a house. Want more?  Listen to SPaMCAST 297 now!

Next week we will feature our interview with Brian Federici.  We discussed working in an environment with a nearly continuous delivery model from the point of view of a practitioner. Does what sounds good in theory really work when it is implemented?

Upcoming Events (more…)

Story points?

Story points?

Recently I did a webinar on User stories for my day job. During my preparation for the webinar I asked everyone that was registered to provide the questions they wanted to be addressed. I received a number of fantastic questions. I felt that it was important to share the answers with a broader audience. 

One of the questions from Grigory Kolesnikov I was asked was indicative of a second group of questions: 

“Which is better to use as a metric for project planning:

  1. User stories,
  2. Local self-made proxies,
  3. Functional points, or
  4.  Any other options?”

Given the topic of the webinar the answer focused on whether story points were the best metric for project planning.

Size is one of the predictors of how much work will be required to deliver a project. Assuming all project attributes, with the exception of size, stay the same, a larger project will require more effort to complete than a smaller project. Therefore knowing size is an important factor in answering questions like “how long will this take” or “how much will this project cost”.  While these are questions fraught with dangers, they are always asked. If you have to compete for work they are generally difficult not to answer. While not a perfect analogy, I do not know a person that builds or is involved in building a home that can’t answer that question (on either side of the transaction). Which metric you should use to plan the project depends on the type of project or program and whether you are an internal or external provider (i.e. whether you have to compete for work).  Said a different way, as all good consultants know the answer is – it depends.

User stories are very useful, both for release planning and iteration planning in projects that are being done with one or small number of stable teams. The stability of the teams is important for the team to be able to develop a common frame of reference for applying story points. When teams are unable to develop a common frame of reference (or need to redevelop the frame of reference due to changes in the team) their application of story points will vary widely.  A feature that in sprint 1 might have been 5 story points might be 11 in sprint 3.  While this might not seem to be a big shift, the variability of the how the team perceives size will also be exhibited in the team’s velocity.  Velocity is used in release planning and iteration planning.  The higher degree of variability in the team’s performance from sprint to sprint, the less predictive. If performance measured in story points (velocity) is highly variable it will be  less useful for project planning.  Simply put, if you struggle to remember who is on your team on a day-to-day basis, story points are not going to be very valuable. 

External providers generally have strong contractual incentives to deliver based on set of requirements in a statement of work, RFP or some other binding document.  While contracts can (and should be) tailored to address how Agile manages the flow of work through a dynamic backlog, most are not, and until accounting, purchasing and legal are brought into the world of Agile contracts will be difficult.  For example, outsourcing contracts many times include performance expectations.  These expectations need to be observable, understandable and independently measureable in order to be binding and to build trust.  Relative measures like story points fail on this point.  Story points, as noted in other posts, are also not useful for benchmarking.  

Story points not the equivalent to duct tape. You can do most anything with duct tape. Story points are a team-based mechanism for planning sprints and releases. Teams with a rotating door for membership or projects that have specific contractual performance stipulations need to use more formal sizing tools for planning.

Story points make a poor organizational measure of software size.

Story points make a poor organizational measure of software size.

Recently I did a webinar on User Stories for my day job as Vice President of Consulting at the David Consulting Group. During my preparation for the webinar I asked everyone that was registered to provide the questions they wanted to be addressed.  I received quite a few responses.  I did my best to answer the questions, however I thought it would be a good idea to circle back and address a number of the questions more formally. A number of the questions concerned using story points.

The first set of questions focused on using story points to compare teams and to other organizations.  

Questions Set 1: Story Points as an Organizational Measure of Software Size

Story points make a poor organizational measure of software size because they represent an individual team’s perspective and can’t be used to benchmark performance between teams or organizations.

Story points (vs function points) are relative measure 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. Every team will have a different perception of the size of work. For example one team thinks that adding a backup to their order entry system is fairly easy and call the work five story points, while a second team might size the same work as eight story points.  Does the difference mean that the second team thinks the work is nearly twice as difficult or does it represent a different frame of reference?  Story points do not provide that level of explanative power and should not be used in this fashion. Inferring the degree of real difficulty or the length of time required to deliver the function based on an outsiders perception of the reported story point size will lead to wrong answers.

There are many published and commercially available benchmarks for function points include IFPUG, COSMIC, NESMA or MarkII varieties (all of which are ISO Standards).  These benchmarks represent data collected or reported using a set of internationally published standards for sizing software. Given that story points are by definition a measure based on a specific team’s perception and not on a set of published rules, there are no industry standards for story point performance. 

In order to benchmark and compare performance between groups, an organization needs to adopt a measure or metric based on a set of published and industry accepted rules. Story points, while valuable at a team level, by definition fail on this point. Story points, as they are currently defined, can’t be used to compare between teams or organizations. Any organization that is publishing industry performance standards based on story points have either redefined story points OR just does not understand what story points represent.

Listen to the Software Process and Measurement Cast 285. SPaMCAST 285 features a compilation of frequently asked questions of a consulting kind.  Working as a traveling consultant, podcaster and blogger provides me with a fabulous mix of experiences. Meeting new people and getting to participate in a wide range of real life experiences is mind expanding and invigorating. Many of the questions that I have been asked during a client engagement, on the blog or in response to a podcast have similar themes. Since most of the answers were provided in one-on-one interactions I have compiled a few of the questions to share. If these questions spark more questions I promise to circle back and add to the FAQ list!

The SPaMCAST 285 also features Kim Pries’s column, The Software Sensei. In this edition, Kim tackles the concept of failure mode and effects.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature an interview with Brian Wernham author or Agile Project Management for Government. Combining Agile and government used in the same phrase does not have to be an oxymoron.

Upcoming Events

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

ITMPI Webinar!

On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 

Untitled

Are function points relevant in 2014? In this case, the question is whether function points are relevant to the size of an application, a development or an enhancement project. IFPUG Function Points were proposed in 1979 by Allan J. Albrecht, published in 1983 by Albrecht and Gaffney while at IBM and then updated and extended over the years. Just like using a tape measure to determine the size of the room, function points are a tool to determine the size of the application or project. In order to determine relevance we need to answer two questions:

  1. Do we still need to know “size”?
  2. Is knowing size sufficient to tell us what we need to know?

Size as a measure has many uses, but the two most often cited are as a component in parametric estimation and as a denominator in metrics such as time-to-market and productivity. While there still might be an intellectual debate on the effectiveness of estimation, there has been no reduction in the sponsors, executives, purchasing agents and the like requesting a price or an end date that you will be held accountable to meet.  Until those questions cease, estimation will be required. Parametric estimation processes (the second most popular form of estimation after making up a number) require an estimate of size as one of the inputs.  Parametric estimation helps to avoid a number of the most common cognitive biases exhibited by IT estimators: optimism and assumption of knowledge.

Size is also used as a normalizing factor (a denominator) to compare effort (productivity), duration (time-to-market) and defects (quality). This type of quantitative analysis is used to answer questions like:

  • Is our performance improving?
  • Are the techniques being used delivering value faster?
  • Are we staffed appropriately?

Function points deliver a consistent measure of functional size based on a consistent set of rules.

The second and perhaps more critical question is whether the balance between functional requirements (things users do) and non-functional requirements (things like usability and maintainability) have changed when implemented in the current environment. If the balance has changed then perhaps measuring functional size is not relevant or not sufficient for estimation or productivity analysis.  A literature search provides no quantitative studies on whether the relationship between functional and non-functional requirements (NFRs) has changed.  Anecdotally, the new architectures, such as heavily distributed systems and software as a service, have caused an increase in the number and complexity of NFRs. However there is no credible academic evidence that a change has occurred.

It should be noted that some measurement organizations, like IFPUG, have developed and begun evolving measures of non-functional size.  IFPUG has released the SNAP version 2.1, which measures the size of NFRs. These measures are still in the process of being incorporated into software estimation tools and are considered an augmentation to functional size measures like IFPUG Function Points or COSMIC (another form of function points).

Function points are still relevant because organizations, sponsors and purchasing agent still want to know how much a project will cost and what they will get for their money.  Organizations still want to benchmark their performance internally and externally.  Answering these kinds of questions require a standard measure of size. Until those questions stop being important, function points will be relevant.

FYI: Many times the question of relevance is really code for: “Do I have to spend my time counting function points?”  We will tackle that issue at a later date, however until then if effort is the real issue, call me and let’s discuss Quick and Early Function Points.

Next Page »