How Agile Estimation Techniques Pave the Way for Successful Product Development
Humans are not good at doing estimations. They belong to two categories when it comes to estimation: underconfident or overconfident, which often leads to underestimation or overestimation respectively. This is the root cause of many product development projects being delivered late or failed to deliver at all.
Estimations are hard and it can be a difficult brute to manage; all the more so on an Agile project. One in six IT projects has a cost overrun of 200%. It’s a big failure of estimation.
From “how much will it cost?” to “how long will it 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.
In my experience, an estimate of any project for more than 3 weeks is quite uncertain.
So, What’s the Purpose and the Benefits of Agile Estimation?
If project estimation and planning is difficult and uncertain, then why do it at all?
Change is inevitable- technology, people, and requirements-even in the Agile Framework. However, Agile Estimation helps in decision making-finding a solution to the overall product development question-What should we build?
Moreover, it 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
Thus, Agile Estimation Techniques 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 because the cycle time of making changes to software products does not compare to the rapid rate of our decision-making. And to make sensible decisions, you need to have a feel for both the cost and the benefits.
2. Better Coordination
“Alone, we can do so little; together we can do so much.”
~ Helen Keller
The X team 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 the team X estimates that they require a month to add the new feature and the team Y estimates that the new service will be built in two months, then the team X knows that it’s not efficient to start today. They have a time of 1 month that they can spend working on some other feature 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 in Agile improves the chances of a project’s success by providing insights into the project’s risks. With the help of Agile Estimation Techniques, you may shortlist the features that are risky and thus can be contained by early attention. The discussions that occur while estimating raise questions that expose 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 an enigma that every software development methodology has aimed to solve.
The best way to showcase these constraints is through ‘balance.’ Scope & Quality being on the 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.
Remember, achieving balance involves practical limits.
- 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 Project
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 many different ways to reach this and some even follow their gut feeling to reach 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. 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 with the client when they visit our 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. Understanding the Client and its Potential Customers
Depending upon the complexity of the problem the application is intended to solve, a UX anchor is taken onboard along with the BA, for the discovery phase. The UX analyst’s prime deliverable is to understand not just the client, but their potential customers as well.
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. Prioritization
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 Method):
- Must-haves: includes the items with the highest business value and the ones that demand lowest effort
- Should-haves: includes the items that are of higher priority, and will need some effort to be delivered
- Could-haves: includes all the backlog items that might be desirable in terms of scope, but are of lower business value
- Won’t-haves: includes those items that are agreed upon to be moved to later releases
5. 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 we directly jump to final product development.
6. Project Estimation
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. This also allows flexibility to load and off-load features, as product development starts. Remember, we are committed to endorsing change, as we get closer to the horizon.
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
a) The end-goal that Soaq wanted to achieve with its app was to help organizations collect and distribute videos smartly in their workplace.
b) A team was setup 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 a 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 which was intuitive, complete, and easy for users to adopt.
d) The product was developed using Agile and Scrum methodologies, 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 project with an aim 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.
Story point estimation, a kind of relative estimation, is typically performed at the Product Backlog Grooming Sessions.
Steps to Successful Story Point Estimation in Agile
The story points approach in Agile Estimation 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 process 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
In order to keep moving on the progressive path of the product development journey, it is critical for stakeholders to make use of Agile Estimation Techniques so that the final product gets delivered within the estimated deadline. Agile project estimation can be run using any of the five techniques listed below:
1. Planning Poker
This technique usually applies when estimating 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. Here, 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 user story, the product owner or customer presents it including all features and requirements. This is then followed by a discussion between both parties — the estimator, and the product owner/customer — where the estimator asks clarifying questions.
2. T-shirt Sizes
This Agile Estimation Technique can be applied when providing a quick and rough estimation to a huge 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 takes place for a consensus and arriving at the final estimate.
3. Dot Voting
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 (here, 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
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
This estimating technique 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 is 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.
Conclusion
Poor estimation is the cause of significant challenges in project management and in the software quality, therefore it is important that the correct use of agile estimation techniques is made in order to avoid issues caused by poor estimation.
Even though estimation in Agile is challenging, yet 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.
Originally published at https://www.netsolutions.com on November 20, 2019.
