Last time, we explained that even though estimating software project timelines is tough, we should do it anyway. We also broadly discussed some of the common estimation techniques.

With that background, we want to go into further detail about the bottom-up software effort estimation technique that works for us.

A critical aspect any estimation technique should capture is time and uncertainty. An estimate that only has time implies a high degree of certainty. This generally is not true for most of the projects.

Bottom-Up Software Effort Estimation Technique

Here it goes : 

• Break Down Work into less complex tasks. 
• Estimate Uncertainty. 
• Calculate the worst-case scenario estimate. 
• Revisit. 
• Track. 

For details, read on:

Break Down Work into less complex task chunks

It is tough to give an accurate estimate to a complex task. Therefore, it is recommended that you break into small chunks. That will remove the number of uncertain variables.

We use the following Sizes:

Complexity                                                                                                     Time

Small                                                                                                                                             1 day

Medium                                                                                                                                        3 days

Large                                                                                                                                             1 Week

Extra-Large                                                                                                                                  2 Weeks

Your estimation gets accurate only when you are very granular in mapping and recording the hours that go towards a project’s completion.

The whole point is to use real wall clock hours and days and idealized “programmer hours.” We should not be overly optimistic here.

So if something might take 3 days but you might get it done in 1 day because you got lucky should still be quoted as medium. On the other hand, don’t be pessimistic by quoting that same task as large to cover your butt.

In an ideal condition, your estimation mostly comprises small and medium tasks as there are few large and might be none extra large. However, you need not to do this in one fell swoop. The bottom-up software effort estimation technique advocates that you can refine the estimate later.

How to Estimate Uncertainty? 

A good software effort estimation technique will capture the uncertainty as well.

“20 to 30 days” is a very different estimate compared to “5 to 45 days” even though both have the same mid-point estimate as 25 days.

It is expected to capture the expected-case vs. best-case scenario.
Once you have quoted the expected time blocks as described in the above section, you will now apply the “if-things-go-wrong” multiplier described below:

Uncertainty Level                                                                                                              Multiplier

Low                                                                                                                                          1.1

Moderate                                                                                                                                1.5

High                                                                                                                                         2.0

Extreme                                                                                                                                   5.0

You can have a different multiplier value. That is quite possible. But defining and sticking to a system helps you to come up with quite accurate quotes.

However, you will like to have more low and moderate uncertainty levels and very few high or extreme uncertainty estimates.

How to arrive at the worst-case scenario estimates? 

The groundwork you have accomplished in your software effort estimation technique in the earlier steps will simplify this. 

Let me explain with an example. 

Task                                                             Complexity                Uncertainty           Expected         Worst-Case    

Creating the filer                                            Medium                          Moderate                       3 days                  4.5

Applying the Automation rule                     Large                               High                               1 week.                2 weeks

Showing an error message                           Small                                Low                                1 day                    3.3 days

Integration with Salesforce                         Extra- Large                    High                               2Weeks               10 Weeks.

Revisit the Software Effort Estimation

Is such a wide range acceptable? If not, then this step steps in. 

The range is so high because you have a few extreme, large, uncertain-level projects. 

You should review those along with your colleagues. Try to brainstorm and find out ways to reduce. 

You should now be breaking down extra-large complexity tasks into small ones. I agree that you would have done that had it been easy. 

The trick here is to revise these tasks again with a group of capable people with you on the board. 

It requires deeper research. You can decide to assign two weeks to work hands on some part of this task chunk and understand the complexity more closely. That will help you break this task into small and medium chunks and keep one large complexity level. 

There is no correct strategy here. The key observation is that if you are dealing with too many uncertain components, you should take some time to break them down into small and easier blocks. 

Track

Track your accuracy so that you can improve over time. This helps to form a feedback loop. 

You project.

You observe how much it deviates. 

You use that knowledge to refine your project in the next time. 

We hope that you will find this software estimation technique useful. Please share your feedback if you use this software estimation technique in your next project. 

The credit for this technique goes to Jacob Kaplan Moss – Co-creator of Django.