In this article however, we will discuss the method we have come to prefer - estimating in man hours. There are a number of reasons we prefer this method, which you can read about in our article ‘Why use hours vs story points?’. This article will instead focus on the method behind how we calculate our estimations with man hours.
The first step we take when estimating a software project is to build out the requirements. You can do this by following the Activity: Reverse Engineering Requirements activity.
Once you have your product backlog you can start your estimations. Depending on the size of your backlog this will take anywhere between one and four hours. Make sure you include a person to represent every role which will be involved in the development. It is recommended you estimate with a minimum of three team members.
The next thing you will need is a method to record and track the estimations. If you would like, you can try our estimations spreadsheet. Then the fun begins!
How do you estimate a software project?
The first step is for a lead to choose a story to estimate. Without discussion, each squad member will then write down their guess of the time it will take to complete the story.
The reason we prefer man hours is that we can still use one of the main listed advantages of story points - a Fibonacci-style sequence. The typical way to apply this using story points is to assign a story 1, 2, 3, 5, 8, 13 points etc. By not allowing estimates to be just any number, we can reflect that as a story gets larger, the complexity multiplies, but developers can’t get caught up on the specifics.
Why is estimating using Fibonacci sequence bad?
As discussed in Why use hours vs story points?, you can use hours to estimate in pretty much the same way you use story points. We originally tried this method, but found it was not quite working in the meetings. It’s important to be aware of how Hollingworth’s central tendency of judgment may be a potential problem when using this style of estimations. Hollingworth’s research describes the bias where humans have a tendency to pick the median number from the range offered. As pointed out by software estimations research expert Magne, this means estimations will be significantly lower using the fibonacci sequence, since the middle-positioned value is definitely not the middle-sized option. The fibonacci scale’s incremental increase means the size dramatically inclines only on the upper half of the scale. People with less experience are more likely to be inclined to pick the middle number of the scale, therefore increasing the chances of picking a lower timeframe for estimations. Essentially people with less experience are more likely to pick the “I don’t know” option, which tends to be the number sitting in the middle.
We experimented instead by using the sequence 1, 2, 4, 8, 16… up to 128 (which we dubbed “fibonacci-like”) and found our estimations were more often realistic, since this creates a higher number in the middle of the sequence. However, this method is still obviously impacted by central tendency judgment to an extent.
This type of estimation can also lead to “loss of information”, as dubbed by Magne. In some cases, we have compiled previous data that a particular task takes 90 hours. However, using the fibonacci-like sequence, estimators can only choose 64 or 128 hours. Not being able to deviate from this scale when there is good evidence to do so, can therefore lead to inaccurate estimations.
What are the advantages of using Fibonacci for estimating?
Like all things though, that doesn’t mean estimating using fibonacci is all bad. The advantage of this method is that it allows us to use discreet time buckets. Mike Cohn (one of the founders of the agile manifesto) notes in his research paper ‘Agile Estimating and Planning’, that an advantage of the Fibonacci sequence is that it allows developers to disaggregate a user story from one large bucket into two preceding buckets, since a bucket is formed by adding the size of two preceding buckets. This process helps us to create optimal user stories for project development.
What is the best way to estimate using man hours?
Despite the risks associated with using a fibonacci-like sequence, this is still the method we currently use for our software estimations. This is because fibonacci lets you estimate more quickly. Individuals spend less time on deriving a specific number for a user story and so the overall estimation process becomes a lot more time efficient.
Written by Jordi Kitto
Software Developer
Jordi developed this very site you’re on right now! And when he’s not working on this site, he is showing off his latest Apple products to everyone in the office, or working on his side hustle
