Agile estimation is about evaluating the effort required to complete each work item listed in the prioritized backlog, which, in turn, helps in better sprint planning. Estimates can be hard to get — how would you know how much time you should spend on working on a product backlog item to get it completed that too in advance? There could be unforeseen impediments that arise in the way, right? This is where Agile estimation techniques come to the rescue.
From Agile project cost estimations to how long it will take to deliver – estimations are part of the daily grind. Your project is likely to go off track without accurate estimations in terms of — budget and time spent to build it.
Let us take a physical world example here. The Sydney Opera House was anticipated to be completed in 4 years with a budget of AUD $7 million. In reality, it took 14 years to get completed and cost AUD $102 million, i.e., — delayed by ten years with a budget percentage difference of 1457%.
If you do not spend time conducting accurate estimations, your product would get delayed exponentially, which, in turn, can increase the chances of you getting outcompeted.
The thumb rule of accurate estimations is to put effort into strategizing around the right Agile estimation techniques instead of making random guesses. This is possible by applying the best agile story estimation techniques to work.
In this blog, we will cover the most popular agile estimation techniques that can help you create better product backlogs, run effective backlog grooming sessions, and improve sprint planning.
What is Estimation in Agile?
Agile estimation is the task for estimating the effort required to complete a prioritized task in the product backlog. This effort is usually measured with respect to the time it will take to complete that task.
Note: No matter how accurately you estimate the effort required to complete a user story in Agile, an estimate is still an estimate. Do not strive to achieve accuracy because requirements can change at any time, and then there are agile anti-patterns and other emerging realities that change the course of development.
Agile teams also do estimations with reference to — story points. A story point is used in Agile Development projects to estimate the difficulty of implementing a given user story. It is measured in relative units assigned to different user stories that require estimation.
In a nutshell, a story point is a number that helps in level estimate the difficulty to build a user story successfully. And the difficulty could be anything related to complexities, risks, and efforts involved.
Agile project estimation also helps to build strong coordination. If project X is dependent on project Y, it gives an overview of the wait time.
Why Run Agile Estimations?
Agile estimations 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
We respect your privacy. Your information is safe.
Why do we Estimate in Agile?
Overestimating and underestimating have been common with the Agile development team, leading to — development and launch times invariably. Though the process is complicated, considering Agile estimation in the initial stages helps with accurate user story estimations and helps stick to the timely deliverables.
Some of the to-the-point benefits of Agile Estimation techniques include:
1. Improved Decision-Making
With accurate, agile estimation, you will be able to conduct effective backlog grooming sessions, which will further help in precise sprint planning. When you make informed decisions and plan well, your user story delivery time will improve.
2. Better Coordination
Let’s say that 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, suppose both the user stories depend on each other and are connected. In that case, you need to prioritize work so that both the user stories get completed simultaneously, thus leading to better coordination among teams.
3. Better Risk Management
Software projects often suffer from exceeding budgets and timelines. To lower down this risk, Agile project estimation is an ideal solution. It helps estimate story points and stick to budgets, estimates, and the project’s scope. The more accurate the estimates, the better are chances of on-time quality delivery.
Stages of Agile Estimation: The Short Discovery Phase
When we start with a project, we have a limited horizon. Thus, we propose a short product discovery phase to tide over this problem. The discovery phase establishes the essential tenet of Agile methodology, which consists of breaking down the requirements into small batch sizes.
This is an exercise that typically takes two to four weeks, depending upon the project’s complexity.
The in-detail process includes:
1. Conduct Stakeholder Interviews
The Business Analyst (BA) assigned to the discovery team revisits any existing documentation you share initially 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): defines 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 BA, along with 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. We then validate if the backlog addresses the scope of the project 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 not just the client but also their potential customers.
The UX analyst works on 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 with the system. The deliverables here would be ecosystem maps, personas, user journeys, and storyboards.
4. Prioritize Requirements
The discovery team gets involved in the agile cost estimation project and works on the high-level backlog once validated by the stakeholder.
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 on the basis of 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 the 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.: Depending upon the budget and time to market, sometimes this step is skipped, and the agile teams directly jump to final product development.
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 we arrive at an estimate that fits the business needs. It also allows flexibility to load and off-load 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.
- 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 they could distribute videos smartly. And this is where we came up with the concept of “unique permissions.”
- After a series of brainstorming sessions both internally and with the client, our 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 developing a Minimum Viable Product (MVP) and releasing it to the target audience for feedback before iterating.
- The MVP was a huge success and had quite a good number of successful releases after that.
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.
Following are the steps involved in the estimation method with story points:
- 1. Identify base stories: Identifying one or multiple base or reference stories that can inspire appropriate sizing of the backlog is very important.
Any other story in the same Sprint can be compared to the first story. And the future Sprints can repeat this process and align on the same scale.
The team should always be confident of this base story.
- 2. Discuss the requirements of the story: It’s the responsibility of the Product Owner or a business analyst to answer the questions and explain what precisely the referred story entails.
- 3. Create a matrix for estimation: The estimation matrix is a numeric scale that is used to evaluate the selected pieces of work. It can be the preferably Fibonacci sequence (…5, 8, 13, 21, 34 …) or the straightforward linear scale (… 3, 4, 5, 6, 7 …).
The reason for preferring the former is simple: the gaps between numbers in this series are more extensive than in the linear scale, making it simpler to compare the difference between the values assigned to separate tasks at hand.
- 4. Choose an Agile estimation technique
- 5. Plan the sprint
- 6. Validate that your estimates are internally consistent among stories as you go along.
What is Sprint Velocity
Teams split their development and processing cycles into separate and distinctive chunks of time that are called Sprints.
These sprints contain a defined set of tasks, and the team performs to finishing all of them within the sprint window.
That says 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 the team. Unfortunately, there isn’t a concrete way to determine that until you finish the first sprint.
But, we can predict the future velocity by analyzing the team’s historical data- keeping track of how many story points were completed.
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 in determining how many sprint cycles will be required to complete the project.
What are the Best Methods for 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 could be something such as — 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Now, the product owner or the analyst reads the user story and describes it to the team, and the team can ask any related queries.
Each team member secretly selects a card number for an estimate, which is 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 uneven estimates, meetings are held, and the next round of voting commences to come up with an estimate everyone agrees with.
When to use:
- If you have a small number of items
- Establish mutual understanding among team members
- Running late-stage estimations
- If you have highly prioritized backlogs
With estimation by analogy in Agile, story sizes are compared with other stories. This relative sizing approach helps in making a better assumption for agile estimations.
For instance, you already estimated a user story A for two weeks. Now, if you come across a user story B that is twice as large compared to user story A, you will assign it a larger estimation number.
For effective Agile estimation using analogy — the triangulation method is widely used. According to the triangulation method, the user story is estimated against similar intent user stories that already have 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.
When to use:
- If retrospectives are a part of the process
- Among teams that have a good mutual understanding
- 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 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.
When to use:
- Run rough estimations
- You are new to Agile estimation
- Have large backlogs
- Run 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.
When to use:
- If you have well-established teams
- Have large backlogs to manage
- Need to estimate a smaller number of items
5. Affinity Mapping
The affinity estimation technique in Agile can be applied when there are fewer backlog items (usually 20-50), and the team size is small. It involves the following steps:
The affinity estimation technique in Agile can be applied when there are fewer backlog items and small team size. It involves the following steps:
a) Silent Relative Sizing
In this step, two cards are placed on a wall or a board in 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 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 period of twenty to sixty minutes. In the case of minimal discussion, the team members can close the activity.
c) Placement of Items in Correct Locations
In this step, team members place the items in suitable positions, 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
In case the product owner observes a discrepancy in the estimations or wishes to discuss more features and requirements of an item with the team members, they can address them and then make the final estimations after discussions.
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.
When to use:
- Estimate a long-term plan for a project
- Gain mutual understanding in the team
- If you have large backlogs to handle
- Run 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.
To start with, pick a random item and place it under a different bucket. Next, pick another user story, discuss all its features and requirements within the group, and place it in the bucket that suits your understanding. Follow the same drill throughout.
When to use:
- To estimate a large number of items
- Enable quick estimations
- If the team is new to Agile estimation
- Estimate long-term plans
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, you need 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 and you suffer impediments on the way?
- Most Likely Value (M): What is the most likely and practical estimate to complete the task?
You can then calculate the average using either of the following methods:
When to use:
- If your team is new to Agile estimation
- Run later-stage estimations
- If you have highly prioritized backlogs
8. Fibonacci Sequence for Story Point Estimation
Fibonacci sequence is a pretty popular scoring scale within some teams- This sequence is the sum of the previous two numbers in the series- 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89… and continued whereas 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 with an answer than trying to come up with the correct number between, say, 4-15. You’ll likely reach a consensus much more quickly.
This also means you can’t average the team’s story points to finalize the estimation. You’ll have to discuss with your team the work and choose the best estimate from a limited set of options.
But the options can still be limited – if you estimate a story with more effort than 34 but less than 55, it has chances of being less accurate.
Who is Involved in Agile Estimation Activity?
Agile estimation techniques should not be implemented by a product owner or a scrum master alone. Everyone on the Agile development team should be involved as collaborative efforts lead to better estimates.
There are two reasons behind this:
- Anyone on the team can be assigned to complete a task. The assigning usually happens when the item appears at the top of the product backlog list. This is why everyone should be involved to know what the user story demands and the corresponding estimation.
- Avoid underestimation or overestimation. The team’s experience and retrospective sessions help understand the intrinsicality of the item and what it will take to complete it. Everyone’s suggestion while estimating helps avoid wrong estimates.
Different Agile estimation techniques help the development team understand how long it will take to complete a user story in advance. The better the planning around estimations, the better the chances of ensuring faster time to market.
The thumb rule for a good estimation — no work item should exceed 16 hours of work. If anything exceeds that limit, break down the large user stories (epics) into smaller, manageable tasks and rerun estimation.
Moreover, consider retrospectives as a good starting point for estimations. Reflecting on your past projects or the past sprints can help your team estimate near accurate story points and rewire their estimation strategy if something is not adding up to productivity.