How do I estimate my agile project?

Function points are an absolute measure of the complexity of a system. It is a global ISO standard, just like the metre or kilogram is defined. Function point analysis works roughly as follows: 

• Estimate the complexity of the system by counting (at a minimum) the number of external interfaces, queries, the number of input and output screens plus the amount of data sources. 
• Multiply this by a factor for the desired quality attributes of the system. The higher the quality, the larger the factor. This gives an absolute number, the number of function points. 
• Then consult a benchmark on the number of hours required per function point, either externally or within your own organisation, and you know the volume of work as input for your planning. 
• This estimation is done by an expert in function point analysis, which can be done using a design sketch, often supported by a tool or spreadsheet that converts the data into estimates in time and money. 

Story points are a relative measure of the effort a team has to put into a piece of work, usually a user or technical story or, at a higher level, a feature. So if a story is estimated to be four points in size, that story is twice as much work as a two-point story, but otherwise the scale is totally meaningless. The number of points is estimated by the team that has to do the work by comparing stories with previous team experience. The main tool is consultation, often supported by planning poker. 

A team arrives at a system estimate by estimating the total backlog containing all the work in points. Once it is known how many points a team completes in a sprint (the velocity), the lead time follows. 

When the team completes a number of stories, an (already better) picture emerges of what a point costs in time (the velocity). Based on this experience, estimates in time and money can then be given. 

I see at least three important purposes for all the counting work: 

1: Estimate in advance 

Uncertainties in both methods lie in the number of estimated points (complexity) and in the estimation of productivity (benchmark/velocity). It makes a big difference whether a team is experienced or not. 

Estimating based on story points with few experienced teams is very unreliable. After all: the team still has little data (previous stories) to estimate relatively, may not yet be very adept at this and the velocity of the team is also not yet known. Using function point counts and benchmarks that hopefully match your own situation as closely as possible (system, branch, maturity, culture, tooling, etc.) is best. The result is an estimate from a single expert who estimates based on global characteristics. 

If the team does have experience, estimates can be made based on comparison material. An estimate can be made using the team velocity that is also known. Estimating is then a team effort: each member of the team will provide input on the size and the planning will be based on the dialogue. We then use the expertise of the people who have to make it and estimate it based on their practice. 

My conclusion: if you have experience, use it and then story points are ideal for this. The estimate then comes from practice and from the people who do the work. If there is none, use function points. 

2: Monitor and adjust 

Once you've started, you want to know if you're on track. If you already started with story points, then I see no reason to switch to function points now. But suppose you started with function points, due to lack of experience. What then? 

With agile working you realize stories in sprints. Stories do not map to function points. After all, the team does not build the separately estimated elements/components from the function point analysis in a sprint, for example a database or a screen, but builds stories with typically a piece of a database, a piece of screen and a bit of an interface at the same time. Or the team builds stories that do not contain these elements at all, or temporary workarounds or refactorings! All work. Function points are not suitable for the team's sprint microplans. That is why an inexperienced team should switch to estimating in story points from sprint one. 

After some time, experience builds up, for example after three to five sprints, and an estimate is made based on story points. The team is experienced to some extent. If 10% of the story points have now been completed, you can extrapolate to the finish line. A reasonable assumption is that the project will take nine times as long. 

The previously issued planning based on function points can then also be compared. Does that estimate on story points now amount to the same as the previously given function points estimate? If this number deviates, this must be reported, because the practice should not be ignored. 

3: Benchmarking 

And what if we want to know afterwards how productive we were compared to other organizations? Or what if we would like to compare this team from our outsourcing partner? Or what if we want to know “how much IT” we now have in-house compared to other organizations? In this case, story points do not help, as they are a relative and not standardized measure. Function points are the appropriate way here. 

Finally, some tips from my practice:

1. Obviously no method works for unknown or very changing specifications! Discuss this with the client. Of course this is allowed. But will it then be time-to-budget?
2. Don't fall into the trap of naming all stories or components in advance. Reason as follows: we previously built system A with X story points, we estimate the new system to be three times as complex, so three times X points. It can be that simple! Of course it can also be done more finely, although in my practice it often turns out that this adds surprisingly little. This can reduce months of planning effort to hours.
3. Ensure good dialogue. Treasures are not polders or who shouts the loudest!
4. Maintain teams and deploy them to similar work. This way, experience is preserved and estimating with story points remains maximally reliable.
5. Be clear about the margins in your planning. Use bandwidths in both estimated points and in the benchmarks/velocities.
6. Be careful: function point analysis does not include “business-logic” complexity in the ISO standard. If your system contains a lot of this, you probably need to correct it.
7. Use the tips from methodologies such as SAFe or LeSS when working with multiple teams, so that you can continue to work with story points.
8. If you do not trust the estimate provided by an experienced team, consider carefully why that is. There is probably something going on in your agile organization that could be improved. Discuss that! Because improvement fits perfectly with Agile!