Top 8 Agile Estimation Techniques (Explained with Examples) (2024)

The Sydney Opera House was expected to complete in 4 years with a budget of AUD 7 million. It took 14 years to complete and cost AUD 102 million. In short, the project experienced a delay of ten years and went 1457% over budget.

The Sydney opera house example shows how quickly projects can get off track. If you don’t conduct accurate estimations, their product will get delayed, and the competition will gain an advantage.

That’s why Agile estimation is essential. It can help you evaluate the time and effort you need to complete work items in your product backlog. It will further enhance sprint planning.

However, it’s challenging to predict accurate estimates. How would a company know the amount of time it will take to complete a product backlog item in advance? How can they account for unforeseen impediments that arise?

That is where Agile estimation techniques come to the rescue. They keep your project on track by helping you estimate your project’s time, budget, and effort.

A rule of thumb for making accurate estimations is to put effort into strategizing around the proper Agile estimation techniques. Therefore, understanding agile story estimation techniques should be a top priority for a business looking to develop a new product.

This blog will cover the most popular agile estimation techniques to manage product backlogs and run backlog grooming sessions effectively. This way, you can quickly improve your sprint planning.

What is Estimation in Agile?

Agile estimation estimates your effort to complete a prioritized task in the product backlog. We measure it for the time it would take to complete that task. As a result, you can plan sprints more accurately.

Trivia: A sprint is a time-boxed interval that defines the time allocated to complete a task.

Note: Even if a business accurately estimates the effort required to complete a user story in Agile, it’s not the final data. Do not strive to achieve perfect accuracy because requirements can change anytime. There are also agile anti-patterns and other emerging realities that change the development course.

Agile teams also make estimations concerning story points. A story point is used in Agile Software Development projects to estimate the difficulty of implementing a given user story. We measure it in relative units assigned to different user stories that require estimation.

A story point is a number that helps estimate the difficulty of building a user story successfully. This difficulty could be related to the complexities, risks, and efforts involved.

Agile project estimation also helps to build strong coordination. If project X depends on project Y, agile project estimation provides an overview of the wait time.

Why Run Agile Estimations?

Agile estimates are essential for

• Making teams accountable for deliverables,
• Inducing discipline across the Agile team,
• Predicting the approximate time, it will take to finish a project,
• Enabling better sprint management,
• Improving team productivity.

Why do Teams Estimate in Agile?

Overestimating and underestimating are both typical for Agile software development companies. It leads to varying development and launch times. Considering Agile estimation in the initial stages can assist in accurate user story estimations. It helps the team stick to the deliverables, and you don’t deflect.

Some of the to-the-point benefits of Agile Estimation techniques include:

1. Improved Decision-Making

With accurate, agile estimation, the development team can conduct practical backlog grooming sessions, which further helps in precise sprint planning. Their user story delivery time will improve when they make informed decisions and plan well.

2. Better Coordination

Let’s say the estimated effort for user story A is two weeks. On the other hand, the estimation effort for user story B is four weeks. Now, both user stories depend on each other and are connected. In that case, the team needs to prioritize work so that both user stories get completed simultaneously. It will lead to better coordination among teams.

3. Better Risk Management

Software projects often suffer from exceeding budgets and timelines. To lessen this risk, Agile project estimation is an ideal solution. Agile product estimation helps estimate story points and stick to budgets, estimates, and the project’s scope—the more accurate the estimates, the better the chances of on-time, quality delivery.

Stages of Agile Estimation: The Short Discovery Phase

When a project starts, the horizon is limited. Hence, it is wise to implement a short product discovery phase to tide over this problem. The discovery phase establishes the essential tenet of Agile development methodology, breaking down the requirements into small batch sizes. It is an exercise that typically takes two to four weeks, depending on the project’s complexity.

Here’s what the in-detail process includes:

1. Conduct Stakeholder Interviews

The Business Analyst (BA) assigned to the discovery team initially revisits any existing documentation shared and extracts the gaps and queries. The BA then conducts regular workshops with the stakeholders to discuss the gaps and clarify doubts in the system workflow.

Based on these workshops, the BA comes up with the business and functional requirements:

Business Requirements Document (BRD): defines the end goal of the project

Functional Requirements Document (FRD): describes the features required to achieve the end-goal

These workshops can be conducted over a call with the client or when they visit the premises to have one-on-one sessions.

2. Define High-Level Product Backlog

The next step of Agile Estimation involves the BA and the Technical Architect. They frame an initial outcome that the stakeholders are looking for with a feasible solution or product.

A high-level product backlog is defined in terms of epics and story titles, which describe the bare bones of the application. They then validate if the backlog addresses the project’s scope for the client.

3. Understand the Client and its Potential Customers

Depending upon the complexity of the problem that the application is intended to solve, a UX design anchor is taken on board along with the BA for the discovery phase. The UX analyst’s prime deliverable is to understand the client and their potential customers.

The UX analyst works on the personas of the possible user group who might use the application, the ecosystem in which the personas will be using it, and the touchpoints of the user personas within the system. The deliverables would include ecosystem maps, personas, user journeys, and storyboards.

4. Prioritize Requirements

The discovery team becomes involved in the agile cost estimation project and works on the high-level backlog after the stakeholder has validated it.

The analysis is employed with the prioritization method to decide which requirements to complete first, which ones can come later, and which ones to exclude. The backlog items are divided based on the MoSCoW method, which segments features based on must-haves, should-haves, could-haves & won’t-haves.

5. Prepare the Minimum Viable Product (MVP) Backlog

Based on the prioritization activity, the BA assembles the requirements as ‘must-haves’ to the backlog and sections them as the requirements for MVP Development. The MVP backlog might also contain a few items from the ‘should haves’ list, ensuring that the product is sufficiently competitive in the market.

P.S.: In some instances, depending on the budget and time to market, this step is skipped, and the agile teams jump directly to developing the fully-fledged product.

6. Estimate the Project Cost and Timeline

The discovery team estimates the MVP backlog to define the estimated cost and timeline for the first release. This is followed by build, rinse, and repeat until they arrive at an estimate that fits the business needs. This also allows flexibility to load and offload features as product development starts.

How Net Solutions Used ‘Short Discovery Phase’ to Build an Intelligent Enterprise Video Platform: Soaq

Soaq was conceptualized and founded in 2015 by a team of people excelling in technology-based learning and development. Daniel Wolfe, Co-Founder at Soaq, approached Net Solutions to develop a corporate YouTube-style “Video-On-Demand” platform.

Our Approach:

• The end goal that Soaq wanted to achieve with its app was to help organizations collect and distribute videos smartly at their workplace.
• A team was set up that initiated the project with a discovery phase starting with brainstorming on how to distribute videos smartly. This is where the concept of “unique permissions” first came about.
• After a series of brainstorming sessions internally and with the client, the product owner and user experience teams came up with a great user flow that was intuitive, complete, and easy for users to adopt.
• The product was developed using Agile Development estimation techniques. The focus was defining and building a Minimum Viable Product (MVP) and releasing it to the target audience for feedback before iterating.
• The MVP was a huge success, and there were a good number of successful releases that followed.

Steps to Successful Story Point Estimation in Agile

The story points approach in the Agile estimation technique uses historical data to compare features of previous, similar projects to generate a precise estimate.
The steps involved in the estimation method with story points are as follows:

• Identify user stories
• Discuss the requirements of the user story. It is the responsibility of the Product Owner or business analyst to answer the questions and explain what precisely the referred story entails.
• Create a matrix for estimation. The estimation matrix is a numeric scale used to evaluate the selected pieces of work. This scale can be the Fibonacci sequence 5, 8, 13, 21, 34) or the straightforward linear scale (3, 4, 5, 6, 7..).
• Choose an Agile estimation technique.
• Conduct sprint planning
• Validate that the estimates are internally consistent and align with the stories as the process goes along

What is Sprint Velocity?

Sprint velocity measures an individual team’s rate of work during an average sprint.

How to Estimate Sprint Velocity

Sprint velocity is the number of story points that can be completed during a sprint by a specific team. Unfortunately, there is no concrete way to determine sprint velocity until the first sprint has been finished.

However, the future velocity can be predicted by analyzing the team’s historical data (i.e., keeping track of how many story points were completed in a previous sprint). The total number of completed story points and measuring the team’s actual velocity during a sprint can be used as a reasonable data count. This will help to determine how many sprint cycles will be required to complete the project.

What are the Best Methods for the Estimation of Software Projects?

In the Agile development journey, estimation plays a vital role in making progress. Here are some of the most popular Agile estimation techniques in use:

1. Planning Poker

Number-coded playing cards are used to estimate an item. The cards are distributed across the team (sized 2-10), with each of the cards representing a valid estimate. The reading on the cards can be a number between 0 to 100. Now, the product owner or the analyst describes the user story to the team, who can ask any related queries.

Each team member secretly selects a card number for an estimate, revealed when all the cards are turned over. The card with the most voting is the finalized estimate for the item under discussion. In case of rough estimates, meetings are held, and the next round of voting commences to come up with an estimate everyone agrees with.

Planning Poker use cases

• There are a small number of items.
• Establishing mutual understanding among team members
• Running late-stage estimations
• The backlogs are highly prioritized

2. Analogy

With estimation by analogy in Agile, story sizes are compared with other stories. This relative sizing approach is helpful when making assumptions relevant to agile estimations.

For instance, a company already estimated user story A for two weeks. Now, if they come across a user story B that is twice as large as user story A, they will assign it a larger estimation number.

For effective Agile estimation using the analogy, the triangulation method is widely used. According to the triangulation method, the user story is estimated against similar intent user stories that have already been estimated.

For example, if the story is bigger than the story estimated at six-story points and smaller than the story estimated at 10 — estimating it at eight will be a good strategy.

Analogy use cases

• If retrospectives are a part of the process
• Among teams that have an excellent mutual understanding
• Among highly experienced teams

3. T-Shirt Size Estimation

In this t-shirt sizing Agile estimation technique, the items are estimated in standard t-shirt sizes (i.e., XS, S, M, L, and XL). This is more of an informal but creative technique, and numbers can be assigned to each user story and categorized under different t-shirt sizes for better understanding.

A story estimated as XS is usually small and requires less effort than the XL story, which is large and has a big estimation number.

T-Shirt size estimation use cases

• Running rough estimations
• The team is new to Agile estimation
• There are large backlogs
• Running early-stage estimations

4. Dot Voting

Dot voting is a useful Agile estimation technique that works well for a small number of user stories. It is easy to implement and is effective as well. Here, all user stories (including descriptions) are written on post-its and placed on the wall or the board to receive votes from the team. They are given four to five dots in the form of stickers (pens or markers may also be used to create dots), which they can use to vote for the user stories of their choice.

Dot Voting use cases

• Well-established teams
• Managing large backlogs
• Estimating a smaller number of items

5. Affinity Mapping

The affinity estimation technique in Agile can be applied when there are fewer backlog items and small team size. Affinity mapping involves the following steps:

a) Silent Relative Sizing

In this step, two cards are placed on a wall or a board opposite corners (one is named Smaller and the other Larger). Next, all the participants receive a subset item from the product owner and are asked to size each item individually.

Here, participants can ask the product owner clarifying questions. In the case of complicated product backlog items, they are taken off the fold and placed separately. This drill consumes five to twenty minutes.

b) Editing the Wall

In step 2, items can be moved from one location to another based on team members’ discretion. Team members can also discuss the design and implementation aspect, given the allotted twenty to sixty minutes. In the case of minimal discussion, the team members can close the activity.

c) Placement of Items in the Correct Locations

In this step, team members place the items in suitable positions, and post discussions. Here, the t-shirt Agile sizing technique, Fibonacci series, etc., can be used to estimate the relative item size.

d) Product Owner’s Prerogative

Product owners use this step to communicate estimation discrepancy, discuss features, or convey requirements to team members. It is essential because addressing all these things prior to final estimations avoids confusion.

e) Export to Project Backlog Management Tool

In this final step, the product owner can save the finalized estimations by exporting them to a product backlog management tool.

Affinity Mapping use cases

• Estimating a long-term plan for a project
• Gaining mutual understanding in the team
• There are large backlogs to handle
• Running early-stage estimations

6. The Bucket System Estimation

This Agile estimation technique can be incorporated when estimating many items (50-500) and is better than planning poker. Here, different buckets (cards) are placed sequentially with values ranging from 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100, and 200 (and more, if required). Next, according to the estimators’ discretion, the user stories (items) are placed within the buckets.

First, pick a random item and place it under a different bucket. Next, choose another user story, discuss all its features and requirements within the group, and put it in the bucket that suits the team’s understanding. Follow the same drill throughout.

Bucket system use cases

• Estimating a large number of items
• Enabling quick estimations
• The team is new to Agile estimation
• Estimating long-term project

7. Three-Point Method

This method loops in the best-case scenario, the worst-case scenario, and the most likely scenario. The average of all these estimates is then calculated to give us the final estimate.
In this method, the team needs to measure time/effort based on the following parameters:

• Optimistic Value (O): How much time/effort will it take if everything is on track?
• Pessimist Value (P): How much time/effort will it take if things fall apart or there are impediments on the way?
• Most Likely Value (M): What is the most likely and practical estimate to complete the task?

Calculate the average using either of the following methods:

Three-Point Method use cases

• The team is new to Agile estimation
• Running later-stage estimations
• There are highly prioritized backlogs

8. Fibonacci Sequence for Story Point Estimation

The fibonacci sequence is a popular scoring scale within some teams. This sequence is the sum of the previous two numbers in the series. For example, 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc. In contrast, the linear sequence is 1, 2, 3, 4, 5, 6, 7, etc.

This comes with its benefits. While looking at a story and determining whether it’s a 5, 8, or 13, it’s quicker and easier to land an answer than to come up with the correct number between, say, 4-15. The team is likely to reach a consensus much more quickly.
The team will have to discuss the work and choose the best estimate from a limited set of options.

The options, however, can still be limited. For example, a story could be estimated as having more effort than 34 but less than 55. In instances like these, this scale has chance of being less accurate.

Fibonacci Sequence use cases

• When estimating for large and complex tasks
• If the need is to prevent estimates from getting too close to each other
• Are concerned about the estimate accuracy

Five best practices for improved agile estimation

1. Start with smaller stories before tackling epics

Estimating smaller stories is much easier than estimating large epics. Hence, pick the low-hanging fruit first and start by focusing on small stories. It would help your team familiarize with the estimating process and improve your chances of creating accurate, agile estimates.

2. Break down epics if they’re too big to tackle

You can also break epics if you find them too difficult to tackle. This way, you can easily create accurate estimates. Smaller epics also help you plan your sprints much better.

3. Follow an iterative approach to agile estimation

You can easily estimate traditional projects 2-3 times. However, agile estimation doesn’t work in the same way. In its case, it’s much wiser to follow an interactive approach and review software development estimates at each sprint. This way, teams can better understand the estimation process and easily break epics into smaller ones.

4. Be a team player

Agile estimation is a team sport that requires active communication and collaboration. You can better predict the time and effort needed to complete a project when everyone from your team is involved. It also encourages active participation within your team, as everyone feels responsible for their work.

It’s also wise to involve subject matter experts in the agile estimation process. They can better consult and guide your team to give the best estimates.

5. Don’t forget to look at the historical data

Historical or industrial data plays a crucial role in agile estimation. Project approaches change, and new methods emerge. Still, the decades-old studies remain relevant and guide you in the tough times.

So, make sure you refer to them during project estimation. You may get a new, radical idea to better plan your agile project estimates.