Estimation Techniques

Estimation is an important aspect of the software development life cycle, where the time and effort required to complete a particular task are estimated before a project begins. 

Estimation is the process of finding an estimate, or approximation, which is a value that can be delivered by completing any particular task. Following are some of the estimation techniques –

1. Story Point Estimation
2. Function Point Estimation
3. Use-Case Point Estimation
4. Wideband Delphi Estimation
5. Analogous Estimation
6. Planning Poker
7. Project Evaluation and Review Technique (PERT)

1. Story Points Estimation - Story Points is an estimation technique for expressing an estimate of the overall effort that will be required to fully implement a product backlog item. When you estimate with story points, you assign a point value to each item. The raw values which you assign to any item are not important. What matters here are the relative values. A story that is assigned a 2-story point should be twice as much as a story that is assigned a 1-story point. It should also be two-thirds of a story that is estimated as 3 story points. Story points constitute an estimate of the relative size, complexity, risks, uncertainty, and effort needed for completing or implementing a user story. It's a high-level estimation technique. The agile estimation uses the Fibonacci series (0, 1, 2, 3, 5, 8, 13, 21…) for the estimation of the size of stories.

2. Function Points Estimation - A Function Point (FP) is a unit of measurement to express the amount of business functionality, an information system (as a product) provides to a user. Function Point measures software size. They are widely accepted as an industry standard for functional sizing.
For estimating software based on Function Point, some recognized standards come into existence. As of 2013, these are − ISO Standards

• COSMIC − ISO/IEC 19761:2011 Software engineering. A functional size measurement method.

• FiSMA − ISO/IEC 29881:2008 Information technology - Software and systems engineering - FiSMA 1.1 functional size measurement method.

• IFPUG − ISO/IEC 20926:2009 Software and systems engineering - Software measurement - IFPUG functional size measurement method.

• Mark-II − ISO/IEC 20968:2002 Software engineering - Ml II Function Point Analysis - Counting Practices Manual.

• NESMA − ISO/IEC 24570:2005 Software engineering - NESMA function size measurement method version 2.1 - Definitions and counting guidelines for the application of Function Point Analysis.

3. Use-Case Points Estimation - Use-Case Points is a software estimation technique used to measure the software size with use cases. The concept of UCP is similar to FPs. The number of UCPs in a project is based on the following −

• The number and complexity of the use cases in the system.

• The number and complexity of the actors in the system.

• Various non-functional requirements (such as portability, performance, and maintainability) are not written as use cases.

• The environment in which the project will be developed (such as the language, the team’s motivation, etc.)

Estimation with UCPs requires all use cases to be written with a goal and at approximately the same level, giving the same amount of detail. Hence, before estimation, the project team should ensure they have written their use cases with defined goals and at a detailed level. The use case is normally completed within a single session and after the goal is achieved, the user may go on to some other activity.
Use-Case Points Counting Process -  The Use-Case Points counting process has the following steps −

• Unadjusted UCPs

• Adjust for technical complexity

• Adjust for environmental complexity

• Calculate adjusted UCPs

4. Wideband Delphi Estimation - In Wideband Delphi Technique, the estimation team comprises the project manager, moderator, experts, and representatives from the development team, constituting a 3-7 member team. There are two meetings −

• Kickoff Meeting

• Estimation Meeting

1. Choose the Estimation team and a moderator.
   
2. The moderator conducts the kickoff meeting, in which the team is presented with the problem specification and a high-level task list, any assumptions, or project constraints. The team discusses the problem and estimates issues if any. They also decide on the units of estimation. The moderator guides the entire discussion monitors time and after the kickoff meeting, prepares a structured document containing problem specification, a high-level task list, assumptions, and the units of estimation that are decided. He then forwards copies of this document for the next step.
   
3. Each Estimation team member then individually generates a detailed WBS, estimates each task in the WBS, and documents the assumptions made.
   
4. The moderator calls the Estimation team for the Estimation meeting. If any of the Estimation team members respond saying that the estimates are not ready, the moderator gives more time and resends the Meeting Invite.
   
5. The entire Estimation team assembles the estimation meeting.

5. Analogous Estimation - Analogous Estimation uses similar past project information to estimate the duration or cost of your current project. We can use analogous estimation when there is limited information regarding the current project. Often, there will be situations when project managers will be asked to give cost and duration estimates for a new project as the executives need decision-making data to decide whether the project is worth doing. Usually, neither the project manager nor anyone else in the organization has ever done a project like the new one but the executives still want accurate cost and duration estimates.

6. Planning Poker - Planning Poker is an agile planning technique aimed at gaining consensus on the estimated time to complete an activity. Team members are given Planning Poker cards with values like 1,2,3,4 and these values represent the estimation unit (hours, days) then, a user story is discussed and the team members are called to disclose the duration that an activity is expected to take by displaying a Planning Poker card. If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates, and the same process is repeated until the complete team reaches a consensus.

7. PERT - Project Evaluation and Review Technique (PERT) estimation considers three values: the most optimistic estimate (O), a most likely estimate (M), and a pessimistic estimate (least likely estimate (L)). The most-likely estimate is weighted 4 times more than the other two estimates (optimistic and pessimistic). PERT Estimate (E) is based on the weighted average and follows the beta distribution.
                                        E = (O + 4 × M + L)/6

  PERT is frequently used along with Critical Path Method (CPM). CPM tells about the tasks that are critical in the project. If there is a delay in these tasks, the project gets delayed.
  Standard Deviation - Standard Deviation (SD) measures the variability or uncertainty in the estimate.
   In beta distribution,
                                Mean = (O + 4 × M + L)/6
                                Standard Deviation (SD) = (L − O)/6

PERT Estimation Steps

•   Step 1 − Arrive at the WBS.
•   Step 2 − For each task, find three values most optimistic estimate (O), the most likely estimate (M), and a pessimistic estimate (L).
•   Step 3 − Calculate the PERT Mean of the three values.
• PERT Mean = (O + 4 × M + L)/3
•   Step 4 − Calculate the Standard Deviation of the task.
• Standard Deviation (SD) = (L − O)/6
•   Step 5 − Repeat steps 2, 3, and 4 for all the tasks in the WBS.
•   Step 6 − Calculate the PERT estimate of the project.
• E (Project) = ∑ E (Task)
•   Step 7 − Calculate the Standard Deviation of the project.
• SD (Project) = √ (ΣSD (Task)²)

Convert the Project Estimates to Confidence Levels - PERT Estimate (E) and Standard Deviation (SD) thus calculated are used to convert the project estimates to confidence levels. The conversion is based such that -

• The confidence level in E +/– SD is approximately 68%.

• The confidence level in E value +/– 1.645 × SD is approximately 90%.

• The confidence level in E value +/– 2 × SD is approximately 95%.

• The confidence level in E value +/– 3 × SD is approximately 99.7%.

   Commonly, the 95% confidence level, i.e., E Value + 2 × SD, is used for all project and task estimates.

One of my team is following Kanban for bug-fixing kind of activities and one of the challenges is to manage the effort estimation of those bugs kind of work items. So, what should I do to improve the effort estimation for my team?

Effort estimation in Kanban for bug fixing activities can be challenging, but there are several strategies you can employ to improve accuracy. Following are my suggestions -

• Historical Data: Collect and analyze historical data on past bug-fixing activities. Look at similar types of bugs, their complexity, and the effort it took to resolve them. This data can serve as a reference for future estimations.
• Break Down Tasks: Break down bug-fixing tasks into smaller, more manageable units. Smaller tasks are often easier to estimate accurately than large, complex ones. Consider breaking them down based on the steps involved in fixing the bug or the components of the system affected.
• Relative Estimation: Use a relative estimation technique, such as story points, to estimate effort rather than absolute units of time. Assign a relative value to each bug based on its complexity, impact, and other factors. This approach allows for easier comparison and prioritization of bugs.
• Involve the Team: Encourage the entire team, including developers and testers, to be involved in the estimation process. Gather their insights and experience to get a more comprehensive understanding of the effort required. Collaborative estimation can lead to better accuracy and buy-in from team members.
• Use Expertise: Leverage the expertise of your team members who have experience in bug fixing. Their knowledge and insights can help in providing more accurate estimates. Encourage open discussions and knowledge sharing to improve the collective understanding of the bugs and their potential complexities.
• Regularly Review and Refine: Continuously review and refine your estimation process. Learn from past experiences, evaluate the accuracy of your estimates, and make adjustments as needed. Over time, you will develop a better understanding of your team's capabilities and improve estimation accuracy.
• Track and Analyze: Keep track of your estimation accuracy and compare it with the actual effort spent on bug fixes. Analyze any discrepancies and identify patterns or areas where the estimation process can be improved. This feedback loop will help refine your estimation techniques over time.

Remember that effort estimation is not an exact science, and there will always be some level of uncertainty. The goal is to continuously improve the accuracy of your estimates over time through learning and adaptation.