It is easy to think of an estimate as one figure. Intuitively, it would seem that a feature such as a user management dashboard should take 5 days to build.
When we ask for an estimate from a developer, then what we expect is this single number.
Yet this single number can be quite misleading as we talked about in Why you should never give off the cuff estimates
You see the number of days it will take to complete any feature is not some kind of physical truth, rather it’s a derived quantity.
In this entry, we shall be looking at how the variables that determine the final delivery date interact with each other.
A trip home
I live and work in Nairobi, once every while, I travel to my hometown in Kisii county. Suppose I called home and told them am coming, the very first question they would ask would be
What time do you expect to arrive?
This question is a simplified version of a client asking a developer, When can I expect feature X?.
Based on my experience travelling home, I probably would be able to give my family a solid estimate fairly quickly. But let’s suppose I did not know much about the trip, then how would I go about coming with an estimate?
How many Kilometres are there between Nairobi and Kisii? (Size)
This is the most important variable and the only one that exists independent of my activities. The distance between Nairobi where I am and Kisii where I want to be is representative of the work that needs to be done.
It is highly likely I would be able to agree with other people on the distance if nothing else.
If our estimate of the distance was to vary, then we probably don’t have a shared understanding of where we are trying to go. Eg if I estimated the distance to be 500km and my brother estimated it at 800km we are probably talking about different destinations or thinking of different roads.
In software, story points are used to indicate the size of the feature. Estimates of story points from different team members tend to cluster around the same value. In case there is a lot of variation, a discussion should ensue. It is probable that there is some misalignment in what the feature is about.
What are my means of transport? (Velocity)
When it comes to speed, means of transport is the most important factor. Will I, for example, be walking, driving or taking a flight. The different means have speeds that once more cluster. For example, walking can be done at 5km/hr driving at 100km/hr and a flight at 800km/hr.
Velocity is likely to vary even for the same classes of transport.
In software teams, velocity is measured via either story points/sprint or features/week. I personally prefer the first measure. While you can estimate this value, the most accurate values would come from looking at how you have performed historically. That is, what is the average velocity you have experienced over the last say three sprints.
The velocity is determined primarily by the skill level of the team followed by the morale and number of team members. In engineering folklore, it is said that the best engineers are 10X as productive as average engineers. Whether this is literally true or not, from experience, I know that progress is much faster with a senior team.
In an ideal situation, how many hours will it take me? (Duration)
The road to Kisii is full of perils. From a couple of black spots, flash flood areas, escarpments and corrupt public officials, there is a lot that can delay your trip. Even with none of this dangers, something as simple as having lunch is likely to increase the time it takes to get home.
So when we think about the ideal situation, we must think of the sunniest day where everything is clear and you maintain a constant speed from Nairobi to Kisii.
To derive duration we can, therefore, employ some basic math:
duration = distance/speed
By using this computation, we can then arrive at the ideal time it will take to arrive.
Similarly, in software, we can calculate the number of story points or features we will deliver in that time period.
time to delivery = story points to deliver / velocity weeks to deliver features = no of features / features per week
In practice how long will it take me? (Calendar time)
In real life, you have to eat lunch. Our task at this time is to determine how much time we will take considering the vagaries of life.
Suppose from previous trips, I know that I usually face some delays such as:
- Jam at the escarpment (1h)
- Slow traffic at flood plains (0.5h)
- Lunch (0.5h)
Once I have arrived at my ideal duration, I would then need to add these hours to it to arrive at the calendar time.
estimated calendar time = ideal time + expected delays
Similarly, in software, there are a lot of factors that affect feature development that is not part of development. In the entry When to ignore historical velocity we talk a bit about such factors.
So then for the software team, once you have arrived at your ideal duration, you can now add in external factors to the estimate to come up with the calendar time. This value is what the client and other stakeholders will likely be interested in. To ensure the estimates are dependable, consider some of this tips
Do you decompose your estimates and in what way? Talk to me in the comment section below or on my twitter @ jchex