Agile estimation techniques give a definite direction to the product development project, thereby paving the way for successful digital products, with faster time-to-market. Estimating work in agile projects is fundamentally different from traditional methods of estimation.
People are not usually great at doing estimations. They belong to two categories when it comes to approximation: under confident or overconfident, which often leads to underestimation or overestimation. In the software development space, this becomes the root cause of many product development projects being delivered late or failing to deliver at all.
Estimations are hard, and they can be challenging to manage; all the more when it comes to Agile estimation techniques. From how much it will cost to how long it will take to deliver – estimations are part of the daily grind when it comes to software development. And most of the tech companies are unable to quantify and measure the reliability of their Agile estimation techniques.
What’s the Purpose and the Benefits of Agile Estimating and Planning?
If project estimation and planning is complicated and uncertain, then why do it at all?
We respect your privacy. Your information is safe.
Change is inevitable— technology, people, and requirements—even in the Agile Framework. However, Agile estimating and planning helps in better decision making—finding a solution to the overall product development question—What should we build?
Moreover, agile estimation also helps to build strong coordination. If project X is dependent on project Y, it gives an overview of the wait time.
The process is called estimation, not exactimation. ~ Phillip Armour(/span)
Thus, the different estimation techniques in Agile are not just about finding the answers to the queries about determining an appropriate deadline or schedule, it helps in many other ways.
1. Better Decision Making
Achievement is talent plus preparation ~ Malcom Gladwell, Outliers: The Story of Success
An estimation-informed decision helps foresee upcoming challenges and opportunities. With regular sprint reviews and sprint retrospectives, a part of agile estimation techniques, there is consistent feedback on the performance that aids in making better decisions that help the project at hand save time and money.
2. Better Coordination
Alone, we can do so little; together we can do so much. ~ Helen Keller
Team X wants to add a new feature to its app, but they are unable to proceed further until the Y team builds a new service to provide vital data. If team X estimates that they require a month to add the new feature and team Y forecasts that the new service will be built in two months, then team X knows that it’s not efficient to start today. They have a time of 1 month that they can spend working on other features that can be released earlier.
3. Better Risk Management
Business people need to understand the psychology of risk more than the mathematics of risk. ~ Paul Gibbons
Estimation techniques in Agile improve the chances of a project’s success by providing insights into the project’s risks. With the help of Agile estimation techniques, you can shortlist the features that are risky and thus can be contained by early attention. The discussions that occur while estimating work raise questions that expose the potential dark corners of a project.
Balancing the 4 Constraints of Agile Estimation
As defined by The Iron Triangle, there are four major constraints of estimation—scope, quality, schedule, and cost. And ensuring successful software delivery within the constraints of “The Iron Triangle” has been a challenge that every software development methodology has aimed to solve.
The best way to showcase these constraints is through balance. Scope & quality being on one side and schedule & cost on the other. If you plan to increase the scope, you will have to either raise the schedule or the cost or reduce quality.
- Cost and schedule are easily measurable
- Quality is relatively hard to measure
- The scope is the hardest to measure
Pro tip: Promote changes to your project but manage scope.
Short Discovery Phase: Stages of Estimation in Agile Projects
In the real world, even though we appreciate the merits of Agile Transformation, and embrace the fact that changes will occur, we want to carve out a budget to estimate our spending. There are different ways to reach this, and some even follow their gut feeling to arrive at the final answer of estimation.
When we start with a project, we have a limited horizon. Thus, we propose a short 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 takes typically two to four weeks, depending upon the complexity of the business’s project.
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 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, in order to decide which requirements to complete first, which ones can come later, and which ones to exclude. The backlog items are divided into must-haves, should-haves, could-haves & won’t-haves MoSCoW Metho:
- Must-haves: include the items with the highest business value and the ones that demand the lowest effort
- Should-haves: include the items that are of higher priority and will need some effort to be delivered
- Could-haves: include all the backlog items that might be desirable in terms of scope but are of lower business value
- Won’t-haves: include those items that are agreed upon to be moved to later releases
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 it as the requirements for the MVP Development.
The MVP backlog might also contain a few items from the ‘should haves’ list, making sure that the product is sufficiently competitive in the market.
PS: 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.
a) The end-goal that Soaq wanted to achieve with its app was to help organizations collect and distribute videos smartly at their workplace.
b) A team was set up that initiated the project with a discovery phase starting with brainstorming on how the videos can be distributed smartly. And this is where we came up with the concept of “unique permissions.”
c) 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.
d) The product was developed using Agile Scrum estimation techniques, the focus was to define and develop a Minimum Viable Product (MVP) and release it to the target audience for feedback and then iterate.
e) The MVP was a huge success and had quite a good number of successful releases after that.
Story Point Estimations in Agile
A story point is used in Agile Development projects to estimate the difficulty of implementing a given user story.
In a nutshell, a story point is a number that informs the team about the difficulty level of the story. And the difficulty could be anything related to complexities, risks, and efforts involved.
Steps to Successful Story Point Estimation in Agile
The story points approach in Agile Estimation method makes use of 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:
- Identify base stories
- Discuss the requirements of the story
- Create a matrix for estimation
- Choose an Agile Estimation Technique
- Plan the sprint
- Validate that your estimates are internally consistent among stories as you go along
Agile Estimation Techniques Used in Software Product Development
To keep moving on the progressive path of the product development journey, stakeholders must make use of Estimation Techniques in Agile so that the final product is delivered within the estimated deadline. Agile project estimation can be run using any of the five techniques listed below:
1. Poker Estimation Techniques in Agile
Planning Poker technique usually applies when determining a smaller number of items within a small team. In this technique, the estimation group gathers in a circular position for the planning poker session. Each estimator is given a set of planning poker cards of values, ranging from 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. These values indicate story points or measure, with which the team would estimate.
When the session commences, the product owner or customer presents the user story, including all features and requirements. This is then followed by a discussion between both parties – the estimator, and the product owner/customer – for clarifications and questions.
2. Agile Estimation Techniques – T-shirt Sizing
This Agile Estimation Technique can be applied when providing a quick and rough estimation of a massive backlog of items. Here, the items are estimated in t-shirt sizes, ranging from XS to XL, which would be later converted to numbers, as per requirements.
In this type of project estimation, the estimators assign a size to the items. If the size offered by each estimator is the same, then that would be considered as the final size. However, in the case of a mismatch, a discussion occurs for a consensus and arrives at the final estimate.
3. Dot Voting Estimation Technique
This estimation technique uses a ranking methodology, in which user stories in the product backlog are ranked from high to low priority in order to push forward the most important user stories.
Here, all user stories (including descriptions), are written in post-ids and placed on the wall or the board, to receive votes from the stakeholders. 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.
Once this is done, the product owner then places an order on the product backlog items, based on the most preferred user stories (one with maximum dots) to the least preferred.
4. The Bucket System Estimation
This project estimation technique can be incorporated when estimating a large no. of items. 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, the user stories (items) are placed within the buckets, according to estimators’ discretion.
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 right bucket upon consensus. Follow the same drill throughout.
5. Affinity Mapping
Affinity estimation technique in Agile can be applied when there are fewer backlog items, and the team size is small. It involves the following steps:
a) Silent Relative Sizing
In this step, on a wall or a board, two cards are placed in opposite corners, one 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. In addition, team members can discuss the design and implementation aspect, given the allotted time span 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, t-shirt sizing, Fibonacci series, etc. can be used for estimating 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.
Poor estimation is the cause of significant challenges in project management and software quality. Therefore it is important that the agile estimation techniques are used correctly in order to avoid issues caused by poor estimation.
Even though estimation in Agile is challenging, it is crucial and, if done right, comes with an overall forceful advantage over any other engagement model for the software development process. It focuses on ensuring a finished piece of software for you at the end of every sprint while helping you save your time and money.