I was recently consulting at a client that decided to become Agile and implement Scrum. A few of us went through the Professional Scrum Master training and returned to work, certified and ready to make a difference.

During those early stages we experimented, adapted and implemented until we had everything running “smoothly”. Then after getting to the running smoothly section of the implementation a few more times, we were finally running smoothly.

Then, out of the blue, business came along wanting to know what the sprint estimates meant in terms of time.

Being inexperienced, we would immediately quote line this and that of manual blah with, “Effort does not equate to time” and similar. But we were never able to substantiate the statement with any reasons of substance. Business, therefore and understandably, became insistent on having an answer.

I recently had a conversation with a new colleague who pointed out that what business was actually asking was, “What is this costing?”. Had we not been so inexperienced and eager to please, we may have realised what was actually being asked and used our existing velocity data to equate cost.

But then we might not have experimented with different estimation techniques.
We would not have seen how badly we were getting our planning wrong.
We may not have discovered that it is possible to determine, with accuracy, the time, in hours, it would take a particular team member to complete a particular task.

So with a huff and a puff off we went to go and solve the “Effort must equal time” challenge.

Experimenting with Estimation.

Scrum does not dictate which estimation technique must be used but rather focuses on the utilisation of the estimation results. So feel free to experiment.

I am going to mention what worked for us and why it worked. Your situation may be different but you’ll never know what’s possible unless you try something new.

As we believed we were having success with planning poker, we started trying to associate time with the estimates. Typically a poker 3 would equate to anything between 4 and 16 hours of work (Yup, anywhere between half a day and two days). Try as we might, we could not get more accurate than that.

The IT General Manager observed this for a while and came to the conclusion that we were not being granular enough during the planning sessions. In his opinion, we were not going into enough detail to be able to estimate any more accurately.

The following morning, he introduced us to Function Point Analysis which he had used for several years for software costing estimations.

Function Point Analysis.
I am not going to explain Function Point Analysis as there are many great sources online.

Instead, for the purposes of this post it is enough to know that it forces everyone involved to think, in detail, about what is required.
For example:
Is the user input with validation or without validation.
Will there be interaction with 3rd party vendor systems.
How does the underlying architecture support what is being requested.
How can we work within the confines of the architecture to achieve what is being requested.

You may already be achieving this with your planning sessions, which is great, but the point of this post is that we were not.

At first glance, we were extremely skeptical of the results that would be realised. Mostly due to the fact that Function Point Analysis was designed to evaluate new or existing software solutions that are supported by detailed specification documentation. This is so far removed from one of Scrum’s core principals that we were tempted to abandon it and try something else.

In the end, we committed to giving it a try and adapted the technique for our Scrum purposes.

Adopting Function Point Analysis.
Through the adoption of FPA we identified the following (in no particular order).

  1. The team does not need all the detail on paper. For example. It is enough to know that a new table or method is required. They do not need to know the data types but they do need to be conscious of the complexity.
  2. The team needs some detail on paper. A great Product Owner should be able to provide this detail. A screen mock up or two and a relatively detailed description of the requirements or user story should be sufficient.
  3. An open discussion platform, free of fear of ridicule is crucial.
  4. Everyone should be encouraged to give input and concur on the identified tasks and their estimates.
  5. As the stories get broken down, the team is actually creating and estimating the tasks.
  6. The estimation is based on the complexity of the task only. No other factors matter.
  7. When tasking the stories, enough detail must be captured for the task to be clear. A one liner is not good enough and will always result in wasted time and frustration.
  8. Through being forced to analyse the requirements, everyone involved in the planning gets to understand the architecture, tools and libraries in use.
  9. Through being forced to analyse, everyone becomes familiar with the work involved and the team is able to support each other during the sprint because of this shared awareness.
  10. The Product Owner is able to apply technical knowledge to the discussions with business and make more informed decisions.
  11. The team can quickly identify a request that requires clarification from business.
  12. FPA starts adding forecasting and prediction value after the third sprint.
  13. Actual time taken to complete a task needs to be manually monitored for the first three sprints in order to get the FP Per Hour benefits.
  14. As the team gains more knowledge and becomes more experienced, the velocity increases and the estimation becomes easier.
  15. The FP Per Hour must be adjusted as skills improve.
  16. Quality is increased as knowledge and experience are increased.
  17. All the teams implementing FPA must agree on the model and it’s implementation. This will ensure consistency to business and across all teams.
  18. If a resource moves from one team to another, he/she should understand the estimation and the expectation.
  19. He/she should also clearly understand his/her own capabilities to allow him/her to organise and plan accordingly.
  20. FPA should be included in the new hire onboarding process within the team.

Getting Value.
Our initial goal was to identify how many Function Points Per Hour each team member could complete.

With this in mind, we continually monitored each individuals progress across the first three sprints. This required a bit of manual work as we did not have the correct tooling.

At the end of the third sprint, we analysed the data and were able to identify an average of the FP Per Hour based on experience level. Using this data, we were able to give the Product Owner estimates on the amount of time needed months before the functionality was required. All we needed was one member of the development team. The remainder were able to continue with the sprint.

We would revisit our FP Per Hour numbers every two months to ensure accuracy.

Getting Real Value.
While working towards achieving our goal, it became abundantly clear that calculating FP Per Hour was just one of the benefits that we were able realise. The real benefits went way beyond or expectations.


I’ll be interested in knowing whether you have had similar success with other techniques. In particular, do you go into great technical detail during planning? If you do, how do you go about getting everyone to think at that level? If not, do you still get fairly accurate estimates and how? How do you manage quality in an environment where you are not thinking at a deep technical level?