In order to successful software project & proper execution of task, the Estimation Techniques plays vital role in software development life cycle. The technique which is used to calculate the time required to accomplish a particular task is called Estimation Techniques. To estimate a task different effective Software Estimation Techniques can be used to get the better estimation.

Before moving forward let’s ask some basic questions like What is use of this? or Why this is needed? or Who will do this? So in this article I am discussing all your queries regarding ESTIMATION.

What is Estimation?

“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.” [Wiki Definition]

<img class="i-amphtml-intrinsic-sizer" alt="" role="presentation" aria-hidden="true" src="data:image/svg+xml;charset=utf-8,” style=”max-width: 100%; display: block !important;”>

The Estimate is prediction or a rough idea to determine how much effort would take to complete a defined task. Here the effort could be time or cost. An estimate is a forecast or prediction and approximate of what it would Cost. A rough idea how long a task would take to complete. An estimate is especially an approximate computation of the probable cost of a piece of work.

The calculation of test estimation techniques is based on:

• Past Data/Past experience
• Available documents/Knowledge
• Assumptions
• Calculated risks

Before starting one common question arises in the testers mind is that “Why do we estimate?” The answer to this question is pretty simple, it is to avoid the exceeding timescales and overshooting budgets for testing activities we estimate the task.

Few points need to be considered before estimating testing activities:

• Check if all requirements are finalize or not.
• If it not then how frequently they are going to be changed.
• All responsibilities and dependencies are clear.
• Check if required infrastructure is ready for testing or not.
• Check if before estimating task is all assumptions and risks are documented.

Software Estimation Techniques

There are different Software Testing Estimation Techniques which can be used for estimating a task.

1) Delphi Technique
2) Work Breakdown Structure (WBS)
3) Three Point Estimation
4) Functional Point Method

1) Delphi Technique:

Delphi technique – This is one of the widely used software testing estimation technique.

In the Delphi Method is based on surveys and basically collects the information from participants who are experts. In this estimation technique each task is assigned to each team member & over multiple rounds surveys are conduct unless & until a final estimation of task is not finalized. In each round the thought about task are gathered & feedback is provided. By using this method, you can get quantitative and qualitative results.

In overall techniques this technique gives good confidence in the estimation. This technique can be used with the combination of the other techniques.

2) Work Breakdown Structure (WBS):

A big project is made manageable by first breaking it down into individual components in a hierarchical structure, known as the Work breakdown structure, or the WBS.

The WBS helps to project manager and the team to create the task scheduling, detailed cost estimation of the project. By using the WBS motions, the project manager and team will have a pretty good idea whether or not they’ve captured all the necessary tasks, based on the project requirements, which are going to need to happen to get the job done.

In this technique the complex project is divided into smaller pieces. The modules are divided into smaller sub-modules. Each sub-modules are further divided into functionality. And each functionality can be divided into sub-functionalities. After breakdown the work all functionality should review to check whether each & every functionality is covered in the WBS.

Using this you can easily figure out the what all task needs to completed & they are breakdown into details task so estimation to details task would be more easier than estimating overall Complex project at one shot.

Work Breakdown Structure has four key benefits:

• Work Breakdown Structure forces the team to create detailed steps:
  In The WBS all steps required to build or deliver the service are divided into detailed task by Project manager, Team and customer. It helps to raise the critical issues early on, narrow down the scope of the project and create a dialogue which will help make clear bring out assumptions, ambiguities, narrow the scope of the project, and raise critical issues early on.
• Work Breakdown Structure help to improve the schedule and budget.
  WBS enables you to make an effective schedule and good budget plans. As all tasks are already available so it helps in generating a meaningful schedule and makes scheming a reliable budget easier.
• Work Breakdown Structure creates accountability
  The level of details task breakdown helps to assign particular module task to individual, which makes easier to hold person accountable to complete the task. Also the detailed task in WBS, people cannot allow hiding under the “cover of broadness.”
• Work Breakdown Structure creation breeds commitment
  The process of developing and completing a WBS breed excitement and commitment. Although the project manager will often develop the high-level WBS, he will seek the participation of his core team to flesh out the extreme detail of the WBS. This participation will spark involvement in the project.

3) Three Point Estimation:

Three point estimation is the estimation method is based on statistical data. It is very much similar to WBS technique, task are broken down into subtasks & three types of estimation are done on this sub pieces.

Optimistic Estimate (Best case scenario in which nothing goes wrong and all conditions are optimal.) = A

Most Likely Estimate (most likely duration and there may be some problem but most of the things will go right.) = M

Pessimistic Estimate (worst case scenario which everything goes wrong.) = B

Formula to find Value for Estimate (E) = A + (4*M) + B / 6

Standard Deviation (SD) = = (B – A)/6

Now a days, planning poker and Delphi estimates are most popular testing test estimation techniques.

4) Functional Point Method:

Functional Point is measured from a functional, or user, point of view.

It is independent of computer language, capability, technology or development methodology of the team. It is based on available documents like SRS, Design etc.

In this FP technique we have to give weightage to each functional point. Prior to start actual estimating tasks functional points are divided into three groups like Complex, Medium & Simple. Based on similar projects & Organization standards we have to define estimate per function points.

Total Effort Estimate = Total Function Points * Estimate defined per Functional Point

Let’s take a simple example to get clearer:

	Weightage	Function Points	Total
Complex	5	5	25
Medium	3	20	60
Simple	1	35	35
Function Total Points			120
Estimate defined per point			4.15
Total Estimated Effort (Person Hours):			498

Advantages of the Functional Point Method:

• In pre-project stage the estimates can be prepared.
• Based on requirement specification documents the method’s reliability is relatively high.

Disadvantages of Software Estimation Techniques:

Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable.

Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on −

• Past Data/Past Experience
• Available Documents/Knowledge
• Assumptions
• Identified Risks

The four basic steps in Software Project Estimation are −

• Estimate the size of the development product.
• Estimate the effort in person-months or person-hours.
• Estimate the schedule in calendar months.
• Estimate the project cost in agreed currency.

Observations on Estimation

• Estimation need not be a one-time task in a project. It can take place during −

  • Acquiring a Project.
  • Planning the Project.
  • Execution of the Project as the need arises.

• Project scope must be understood before the estimation process begins. It will be helpful to have historical Project Data.

• Project metrics can provide a historical perspective and valuable input for generation of quantitative estimates.

• Planning requires technical managers and the software team to make an initial commitment as it leads to responsibility and accountability.

• Past experience can aid greatly.

• Use at least two estimation techniques to arrive at the estimates and reconcile the resulting values. Refer Decomposition Techniques in the next section to learn about reconciling estimates.

• Plans should be iterative and allow adjustments as time passes and more details are known.

General Project Estimation Approach

The Project Estimation Approach that is widely used is Decomposition Technique. Decomposition techniques take a divide and conquer approach. Size, Effort and Cost estimation are performed in a stepwise manner by breaking down a Project into major Functions or related Software Engineering Activities.

Step 1 − Understand the scope of the software to be built.

Step 2 − Generate an estimate of the software size.

• Start with the statement of scope.

• Decompose the software into functions that can each be estimated individually.

• Calculate the size of each function.

• Derive effort and cost estimates by applying the size values to your baseline productivity metrics.

• Combine function estimates to produce an overall estimate for the entire project.

Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost estimates by breaking down a project into related software engineering activities.

• Identify the sequence of activities that need to be performed for the project to be completed.

• Divide activities into tasks that can be measured.

• Estimate the effort (in person hours/days) required to complete each task.

• Combine effort estimates of tasks of activity to produce an estimate for the activity.

• Obtain cost units (i.e., cost/unit effort) for each activity from the database.

• Compute the total effort and cost for each activity.

• Combine effort and cost estimates for each activity to produce an overall effort and cost estimate for the entire project.

Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if widely divergent estimates occur conduct further investigation concerning whether −

• The scope of the project is not adequately understood or has been misinterpreted.

• The function and/or activity breakdown is not accurate.

• Historical data used for the estimation techniques is inappropriate for the application, or obsolete, or has been misapplied.

Step 5 − Determine the cause of divergence and then reconcile the estimates.

Estimation Accuracy

Accuracy is an indication of how close something is to reality. Whenever you generate an estimate, everyone wants to know how close the numbers are to reality. You will want every estimate to be as accurate as possible, given the data you have at the time you generate it. And of course you don’t want to present an estimate in a way that inspires a false sense of confidence in the numbers.

Important factors that affect the accuracy of estimates are −

• The accuracy of all the estimate’s input data.

• The accuracy of any estimate calculation.

• How closely the historical data or industry data used to calibrate the model matches the project you are estimating.

• The predictability of your organization’s software development process.

• The stability of both the product requirements and the environment that supports the software engineering effort.

• Whether or not the actual project was carefully planned, monitored and controlled, and no major surprises occurred that caused unexpected delays.

Following are some guidelines for achieving reliable estimates −

• Base estimates on similar projects that have already been completed.
• Use relatively simple decomposition techniques to generate project cost and effort estimates.
• Use one or more empirical estimation models for software cost and effort estimation.

Refer to the section on Estimation Guidelines in this chapter.

To ensure accuracy, you are always advised to estimate using at least two techniques and compare the results.

Estimation Issues

Often, project managers resort to estimating schedules skipping to estimate size. This may be because of the timelines set by the top management or the marketing team. However, whatever the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to accommodate the scope changes.

While estimating, certain assumptions may be made. It is important to note all these assumptions in the estimation sheet, as some still do not document assumptions in estimation sheets.

Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often treated as though they are accurate.

The best way of expressing estimates is as a range of possible outcomes by saying, for example, that the project will take 5 to 7 months instead of stating it will be complete on a particular date or it will be complete in a fixed no. of months. Beware of committing to a range that is too narrow as that is equivalent to committing to a definite date.

• You could also include uncertainty as an accompanying probability value. For example, there is a 90% probability that the project will complete on or before a definite date.

• Organizations do not collect accurate project data. Since the accuracy of the estimates depend on the historical data, it would be an issue.

• For any project, there is a shortest possible schedule that will allow you to include the required functionality and produce quality output. If there is a schedule constraint by management and/or client, you could negotiate on the scope and functionality to be delivered.

• Agree with the client on handling scope creeps to avoid schedule overruns.

• Failure in accommodating contingency in the final estimate causes issues. For e.g., meetings, organizational events.

• Resource utilization should be considered as less than 80%. This is because the resources would be productive only for 80% of their time. If you assign resources at more than 80% utilization, there is bound to be slippages.

Estimation Guidelines

One should keep the following guidelines in mind while estimating a project −

• During estimation, ask other people’s experiences. Also, put your own experiences at task.

• Assume resources will be productive for only 80 percent of their time. Hence, during estimation take the resource utilization as less than 80%.

• Resources working on multiple projects take longer to complete tasks because of the time lost switching between them.

• Include management time in any estimate.

• Always build in contingency for problem solving, meetings and other unexpected events.

• Allow enough time to do a proper project estimate. Rushed estimates are inaccurate, high-risk estimates. For large development projects, the estimation step should really be regarded as a mini project.

• Where possible, use documented data from your organization’s similar past projects. It will result in the most accurate estimate. If your organization has not kept historical data, now is a good time to start collecting it.

• Use developer-based estimates, as the estimates prepared by people other than those who will do the work will be less accurate.

• Use several different people to estimate and use several different estimation techniques.

• Reconcile the estimates. Observe the convergence or spread among the estimates. Convergence means that you have got a good estimate. Wideband-Delphi technique can be used to gather and discuss estimates using a group of people, the intention being to produce an accurate, unbiased estimate.

• Re-estimate the project several times throughout its life cycle.