fpa

Measuring Scrum team productivity/speed with Function Point Analysis

I bought my first copy of Agile Software Development with Scrum, by Schwarber and Beedle back around 2002, I think. I was just thumbing through it last night when I saw that they use Function Points as a metric to demonstrate the velocity that agile software teams achieve, and more specifically use it to show that some teams develop software much faster using Scrum.

I didn’t know about Function Point Analysis back in 2002 — I didn’t become a Certified Function Point Specialist until about two years later — so I probably just skimmed over that line then, but when I saw it last night I thought it was cool that they used function points as a metric for software team development speed.

The best UML “Use Case” definition I know

Every time I read an article or book about UML “Use Cases” I cringe a little bit. Every author says something like “Jacobson left the definition of a Use Case too open,” and then they try to work through some elaborate scheme of what a Use Case means to them. IMHO, the best use case definition was created in the early 1980s, long before Jacobson mentioned the term.

How I make very early software cost estimates (Part 1)

Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.

The problem

Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.

The solution

I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:

Software cost estimating in an agile development environment (PDF)

I’m currently working on a trilogy of “books” (booklets) about software cost estimating, and the third book in the series is about estimating the time and cost of software development projects in an agile development environment. The book isn’t complete yet, and some of it may not make sense without the first two books in the series, but I thought I’d release it here today, as almost everyone has some sort of “agile” development environment going today (or at least I hope so).

How to know when a software requirements specification process is done

Summary: This short article describes a way to know when a software requirements specification is complete by using Function Point Analysis techniques.

I've written dozens — maybe hundreds — of software requirement specifications over the years, and at one point in my career I learned an important little secret about knowing when the process of gathering requirements for a software requirements specification was really complete. Here's my secret.

Free Function Point Analysis software (Sleetmute.com)

Update: Sorry, the Function Point Analysis application that was described in this article is no longer available. I may bring it back to life at some point in the future, but for now it’s offline.

Software metrics: A Tufte-inspired graph for software development projects

I couldn't sleep last night so I started reading Edward Tufte's "The Visual Display of Quantitative Information", and I started thinking about software project metrics that might be useful to the team members on a software development project (including developers, business analysts, domain experts, and stakeholders), and how I would show these metrics in simple but data-filled Tufte charts and graphs.

Dear Business Analyst: If you can’t count the Function Points, you’re about to enter a world of hurt

One of the great things about Function Point Analysis (FPA) is that it can be a terrific validator of the work you’re doing as a business analyst. For example, here’s one of the guidelines I came up with after I learned about FPA:

If you can’t count the Function Points when you’re about to start developing a software project, you’re about to enter a world of hurt.

Software cost estimating with Function Point Analysis

Someone asked the other day if I've written any longer tutorials on software cost estimating and/or Function Point Analysis. Sometimes I forget that this site has grown pretty large, and things like this may not be easy to find with the current design.

To help solve that problem in the short term, here are links to two software cost estimating and Function Point Analysis (FPA) tutorials I've written: