There are a number of effort estimation techniques used in software development, each with its own advantages and disadvantages. Some of the most common effort estimation techniques used in Waterfall & Agile methodologies include:
Top-down estimation: This method involves estimating the total effort required for the project, and then breaking it down into smaller tasks. This can be a quick and easy way to get an initial estimate, but it can be less accurate than other methods.
Bottom-up estimation: This method involves estimating the effort required for each individual task, and then adding those estimates together. This can be more accurate than top-down estimation, but it can also be more time-consuming.
Three-point estimating: This method involves estimating the best-case, worst-case, and most likely effort required for a task. This can help to account for uncertainty and risk. This project estimation method originated from the PERT (Program Evaluation and Review Technique). It uses optimistic, most likely and pessimistic estimates to forecast the final project estimate. The resulting figure is calculated as a weighted average of these three separate estimates through the following formula:
Parametric estimating: This method uses historical data to estimate the effort required for a task. This can be a very accurate method, but it requires a significant amount of historical data.
Analogy-based estimation: This method estimates the effort required by comparing it to the information gathered from past projects or similar features.
Expert judgment: This method relies on the expertise of experienced professionals to estimate the effort required.
Below some of effort estimation techniques used in Agile Development:
T-shirt size estimation: This is a relative estimation technique in which tasks are assigned t-shirt sizes (XS, S, M, L, XL, XXL) to represent their relative size. This can be a quick and easy way to get an initial estimate, but it can be less accurate than other methods.
Planning Poker: This is a consensus-based estimation technique in which team members estimate the effort required for a task by playing cards. This can be a good way to get everyone involved in the estimation process and to reach a consensus on the estimate. Planning Poker is an exercise that involves the entire development team. Traditionally, each member has a deck of cards that shows the numbers of the story point scale. As stories are reviewed, each team member silently arrives at a score and then all team members reveal their selected card at the same time. The team then discusses the scoring, and members contribute their rationale for the score they awarded. After discussion, the team again votes with their cards. The goal, and typical outcome, is to converge upon a single, agreed-upon score within a few rounds.
Story points: Story points are a unit of measurement used in agile development to estimate the effort required to complete a user story. Story points are typically assigned using the Fibonacci sequence, which is a series of numbers starting with 0 and increasing by 1, 2, 3, 5, 8, and so on.
Relative mass estimation: This is a relative estimation technique that uses a scale of weights to represent the relative size of tasks. This can be a good way to estimate the size of complex tasks.
Bucket System - Much quicker than planning poker is the Bucket System. This system is a decent substitute when estimating a large number of items with a large group of participants quickly. Different buckets are created with values: 0,1,2,3,4,5,8,13,20,30,50,100, 200. The stories need to be placed within these where the estimator finds them suitable. The group estimates the items by placing them in these “buckets”. Buckets are usually different sheets of brown paper where you can place the sticky note with the item. But you can also use actual baskets to limit discussion about already processed items.
Dot voting: This is a voting-based estimation technique in which team members vote on the effort required for a task. This can be a good way to get everyone involved in the estimation process and to reach a consensus on the estimate.
The best estimation technique for a particular project will depend on a number of factors, including the size and complexity of the project, the availability of historical data, and the team's experience. It is important to use a combination of estimation techniques to get the most accurate estimate possible.
Here are some additional tips for estimating software development projects:
Start early: The earlier you start estimating, the more accurate your estimates will be.
Involve the team: Get input from the team members who will be working on the project. They will have the best understanding of the tasks involved and the amount of effort required.
Use historical data: If you have done similar projects in the past, use that data to estimate the effort required for the current project.
Be realistic: Don't underestimate the effort required. It's better to overestimate and be pleasantly surprised than to underestimate and fall behind schedule.
Be flexible: Things don't always go according to plan, so be prepared to adjust your estimates as needed.
