Agile estimation is about evaluating the effort required to complete each work item listed in the prioritized backlog, which, in turn, helps improve sprint planning. Estimates can be hard to grasp. How should a company know the amount of time it will take to complete a product backlog item so far in advance? How can they account for unforeseen impediments that arise? 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. The project is likely to go off track without accurate estimations in terms of budget and time.
The Sydney Opera House is a good physical example of how a project can quickly get off track. The Sydney Opera House was anticipated to be completed in 4 years with a budget of $7 million AUD. In reality, it took 14 years to be completed and ended up costing $102 million AUD (i.e., delayed by ten years with a budget percentage difference of 1457%).
If a business does not spend time conducting accurate estimations, their product would get delayed exponentially, which, in turn, can increase the chances of them getting outcompeted.
A rule of thumb for making accurate estimations is to put effort into strategizing around the right Agile estimation techniques rather than making random guesses. Therefore, familiarizing themselves with agile story estimation techniques should be a top priority of a business looking to develop a new product.
This blog will cover the most popular agile estimation techniques that help manage product backlogs, run effective backlog grooming sessions, and improve sprint planning.
What is Estimation in Agile?
Agile estimation is the process 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, which, in turn, leads to accurate sprint planning.
What is a Sprint? A sprint is a time-boxed interval that defines the time allocated to complete a task.
Note: No matter how accurately a business estimates the effort required to complete a user story in Agile, an estimate is still an estimate. Do not strive to achieve perfect accuracy because requirements can change at any time. There are also agile anti-patterns and other emerging realities that change the course of development.
Agile teams also make 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. This is measured in relative units assigned to different user stories that require estimation.
In a nutshell, a story point is a number that helps estimate the difficulty of building a user story successfully. This difficulty could be anything related to the complexities, risks, and efforts involved.
Agile project estimation also helps to build strong coordination. If project X is dependent on project Y, agile project estimation provides 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
Why do Teams Estimate in Agile?
Overestimating and underestimating are both common for Agile development teams which leads to varying development and launch times. Though the process is complicated, considering Agile estimation in the initial stages can assist with accurate user story estimations and helps the team 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, the development team will be able to conduct effective backlog grooming sessions, which will further help in precise sprint planning. When they make informed decisions and plan well, their 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, the team needs to prioritize work so that both 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 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. Thus, it is wise to implement 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 shared 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 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 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 within the system. The deliverables here would be 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 it has been 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 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 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.: 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 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.
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 they could distribute videos smartly. This is where the concept of “unique permissions” first came about.
- After a series of brainstorming sessions both 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 that is 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 …).
Many teams prefer the Fibonacci scale because the gaps between numbers in this series are more extensive than in the linear scale. This simplifies visualizing the difference between the values assigned to the separate tasks. - 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 not a 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 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 describes the user story 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.
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 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 a good 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 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 a 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 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 a case where 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 should address these topics prior to making the final estimations.
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.
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 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 projects
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
Fibonacci sequence is a 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. 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 more effort than 34 but less than 55. In instances like these, this scale has chances 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
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 because 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. Everyone should be involved to ensure they know 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 a user story. Everyone’s suggestion while estimating helps avoid inaccurate estimates.
Conclusion
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 rule of thumb for a good estimation is that 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 past projects or the past sprints can help the team estimate near accurate story points and rewire their estimation strategy if something is not adding up to productivity.
