How to estimate a software project / service (Bonus with web tool at the end)

Step 1: Understand the nature of Software Estimates

Steve “ardalis” Smith's article outlining the Laws of Software Estimates is one of the best available. To summarize:

• Estimates are Waste:
  The more time and effort you waste on estimating, the more wasteful the estimates become. Therefore, it is vital to plan your estimating-pipeline that costs the least time and effort.

• Estimates are Non-Transferable:
  “One individual’s estimate can’t be used to predict how long it might take another individual to complete a task.” While it is true that different teams/individuals may execute a same task/service in different times due to the difference in development techniques, the techniques in Estimating can still be learnt and refined with each other (which is the reason this article exists).

• Estimates are Wrong:
  “Nobody should be surprised when estimates are wrong; they should be surprised when they are right. If estimates were always accurate, they’d be called exactimates.” This law is also to help control the expectations of the stakeholders around the Estimates. More than often, one reason why some Estimates are wasteful is the ones performing the Estimates as much correct as possible. The goal of Estimating should not be making Estimates correct. It should be minimizing the error/deviation of the current and future Estimates.

• Estimates are Temporary:
  An estimate for a service today can be different for the same service next month, as important factors such as requirements and resources can be changed over time. That is why most of the quotation documents state the expiry date of the Estimates (typically 30 days after the issuance).

• Estimates are Necessary:
  There are many reasons why Estimates are necessary. I myself find that even Good Estimates require many reviews / retrospectives over Bad Estimates.

There are many techniques to Estimate. Some of easiest ways are to seek assistance from an experienced estimator, or to use the past Estimates of the same or similar services/tasks. However, let’s assume the worst case where these circumstances are not available (which is likely, due to the Laws above), and the below steps will outline a more suitable approach for that case.

Step 2: Breakdown

You cannot simply just estimate a requirement such as “Build a Book Borrowing App” in 90 days.

Breakdown the project / service, detailing smaller tasks in the manner where you can make estimate on each of them. Remember, the bigger a task’s estimate, the higher its error. Therefore, if you find yourself having a task’s estimate exceeding certain threshold, e.g. 1 working week / 5 working days, ask yourself and your team whether the task can be broken down further.

An example of broken down tasks can be:

• Create schema for Book, User profile in database.

• Implement browsing use case.

• Implement borrowing use case.

• …

• Implement the reminder service for overdue books.

• Create consistent UI on web for all the use cases.

• Document the use cases into User Guide.

• …

• Deliver the App to Staging environment.

• Gather and refine User feedbacks.

• …

• Deliver the App to Production environment.

It is highly recommended that the breakdown should be done concurrently with or after the Requirement / Business Analysts gathering the sufficient requirements for the project / service.

Step 3: Estimate each of the tasks, in terms of E and SD

Define the Expected Value (E) and Standard Deviation (SD) for each of the broken down tasks.

One reliable technique is Three-point Estimations. The technique is to query the person or the team who have experience in perform that task, or will likely perform that task, to estimate the Best case (a), Likely case (m), and Worst case (b) values of the task.

Then, calculate E = (a + 4m + b) / 6, and SD = (b - a) / 6.

For example, if a team member says a task is likely completed in 2 days (m = 2), but can be completed early in 1 day (a = 1) or in worst case taking 1 working week (b = 5), E would be 2.33 and SD would be 1.67.

Another technique is to estimate based on percentage of another task or group of tasks. For example, one may estimate the E and SD of the task to code-review of a service to be 10% of that service’s E and SD.

There can be tasks which you are certain about the time it takes to execute. In these case, you can determine the time value as E while leaving SD as 0 for those tasks.

Step 4: Calculate the E and SD of all tasks / group of tasks

Let’s say a project is a collection of tasks. The E and SD of the project are calculated with the following formulae:

E(project) = Sum( E(task) )

SD(project) = Sqrt( Sum ( SD(task)² ) )

Step 5: Determine Confidence Level

Determine the Confidence Level for your project / service. There are 3 typical levels of Confidence:

• 68% - for low-risk projects

• 95% - for medium-risk projects. It is also used by most Information Systems’ estimates. Choose this if you are not sure where to start first.

• 99.7% - for high-risk projects.

Step 6: Calculate the Contingency and Final Estimate

Based on the Confidence Level determined, you can define the Contingency as:

• 68% → 1 x SD

• 95% → 2 x SD

• 99.7% → 3 x SD

From the Contingency value, you can determine the Confidence Interval of your project, from E - Contingency to E + Contingency.

You can consider using the E + Contingency as a Final Estimate.

Step 7: Understand and use the Estimate Units correctly

There are 2 typical types of Estimate Units:

• Man-hours / Man-days / Man-weeks / Man-months:
  These units are the likely units for the Final Estimate you acquire in earlier steps. They represent the actual time used to complete the tasks, not counting any break times, off days, or times used for different commitments. They are usually used to determine the monetary value to compensate the service of the tasks, and commonly referred in the quotation documents.

• Calendar-hours / Calendar-days / Calendar-weeks / Calendar-months:
  These units represent the time expected as the deadline to complete the whole project since its start. They include times such as off days or holidays. They also include factors such as certain tasks having to wait until certain conditions met, like other tasks completed; or human factors such as commitment levels of the team or whether multiple tasks can be done concurrently.

A common case where these units used wrongly is the value of Man-units are to be used as if Calendar-units, disregarding the factors necessary to include for Calendar-units. For example, a project manager sees a project estimated with 3 Man-days and expects it to be done in 3 Calendar-days after assigning to a team member. However, if that team member is also assigned to another project with commitment level at least 50%, the Calendar-days of the project should be at least 6. Another example is a project with 30 Man-days are expected to complete in 15 days when there are 2 team members assigned to it. This can only be possible when the tasks inside the project can be divided into 2 equal parts that can be done concurrently. Otherwise, this case is no different from “Having 9 women to deliver 1 baby in 1 month.”

Step 8: Retrospective

After the estimated tasks are completed, your team should look back and reflect whether the estimates are underestimated or overestimated. This can include refining the E and SD values of some tasks, or altering the Confidence Level (lower the level for low-risk, or increase for high-risk).

This step will help refine and create better Estimates for the next projects / services.

Bonus:

I create a web tool to help perform the Estimating as above at https://peter-do-stuff.azurewebsites.net/estimator

Please feel free to try out and give feedbacks if any.