Picture this: You have an idea for a product and you want to build it fast. Even though you do not have complete clarity of the requirements, you believe you will be able to define them with the help of your technology partner. You then discuss the product idea with your potential partner, and they recommend you use Agile methodology. You then insist on getting a budget estimate without delaying the release date of your product.
If this sounds familiar, then you have found yourself in a very common situation – “estimation in Agile”, often means the fear of exceeding your budget, you will find this article quite useful.
In Agile, estimations are certainly challenging. While there is one school of thought questioning if the estimations are worth it, here at Net Solutions, we go about it in a different way.
We defy the notion that Agile estimations are futile. There are definitely ways to estimate a project within the Agile framework, and we will explain them thoroughly.
You should first look at the following to estimate the success of your project, test it in each of these scenarios.
Given the above two scenarios, which builder would you choose? Knowing that, your family and friends are your main advisors, you will likely come up with several new ideas during the course of the construction of your dream home.
I hope this gave you some clarity of the benefits and scope for estimations in Agile, and what you should expect when engaging in the Agile methodology approach for converting your business ideas into a digital product. Now let’s look into the main purpose of estimation in Agile.
The purpose and benefits of estimation in Agile
Ensuring successful software delivery within the constraints of “The Iron Triangle” has been an enigma that every software development methodology has aimed to solve.
These three dimensions of scope, cost, and schedule, are interdependent. In any scenario, it is only possible to make one of these three dimensions constant. For developing software within a certain cost, the scope and schedule will have to be kept variable. Similarly, if the schedule or a deadline is constant, the scope and cost need to be variable. It is impossible to fix more than one. It would elude the DNA of software development.
Taking a step back, the Iron Triangle is a legacy handed down to the software development world, by the world that built cars and buildings — a world where cost, scope and schedule, were based on properties. These could be estimated in detail prior to manufacturing, planning that could further be handed off to the builders — plans that did not change after the assembly process started.
Software delivery is another world. The requirements and scope keep changing, so the main questions that arise are – How do we estimate the cost? How do we plan for the schedule?
Enter the proponents of Agile methodology, endorsing the fact that change is at the core of software development; so, rather than fight change, we learn to manage change.
Agile methodology at its core uses the technique of breaking down the work into small batch sizes, and uses continuous market feedback to guide progress. Unlike the assembly line where the customer does not see the product till the end, in Agile, a small increment of the product is available for a “show and tell” at short intervals. Decisions can be made if the plan is adhered to, or if there are course corrections. Build what is needed not what was planned.
The cost involved in this methodology is essentially the cost of the dedicated team that comes together to deliver.
How we estimate software development projects within our Agile framework
In a real world, even though we appreciate the merits of Agile, and embrace the fact that changes will occur, we want to carve out a budget to estimate our spending. When we start with a project, we have a limited horizon.
At Net Solutions, we propose a short discovery phase to tide over this problem.
The discovery phase establishes the essential tenet of Agile methodology, that 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.
The discovery phase unfolds as follows:
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. These workshops can be conducted over a call with the client, or with client visits to our premises, to have one-on-one sessions.
2. Define high-level product backlog
The BA, along with the Technical Architect, frames 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 you.
3. Information architecture
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 you, but your customer 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 & storyboards. The primary deliverable from the UX anchor, would be to provide complete information architecture for the application, giving an overview of the system.
The discovery team works on the high-level backlog, once validated by the stakeholder. 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 have’:
- The items with highest business value, and lowest effort involved, are often the items that qualify the ‘must haves’ criteria.
- The items that are of higher priority, and will need some effort to be delivered, are deemed, as ‘should haves’.
- All the backlog items that might be desirable in terms of scope, but are of lower business value are segmented, as ‘could haves’.
The items that are agreed upon to be moved to later releases, are filtered out as ‘won’t haves’ for now.
5. 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 achieving a Minimum Viable Product (MVP). 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.
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 committed to endorse change, as we get closer to the horizon.
Deriving an estimate
Listed below are the important techniques for estimating:
- Expert opinion
While the above three can be used individually, they derive better results when used collectively. Let’s look at how:
1. Expert opinion
Generally, asking an expert about the project duration or the project size is one approach. However, the responses are usually based on intuitions or gut feelings, which is not quite successful with Agile-based projects. It is essential to note that in agile projects, user stories, or other user-valued functionality, provide an estimate; and, this functionality is not an outcome of an individual effort but entails a combined effort, as this encompasses a variety of skillsets. Finding suitable experts with diverse expertise, across all disciplines, becomes a challenge.
Unlike traditional projects, where tasks have individual ownership, estimating a project becomes easy. Project estimation by an expert opinion, has the advantage that it has a short duration. In this case, a developer goes through a user story, asks clarifying questions, and then offers an estimate based on their understanding. Research shows that this type of estimation scales higher than the analytical approaches (Johnson et al. 2000).
2. Estimating by analogy
In addition to expert opinion, estimating by analogy is another method: for example – “this user story is bigger than that user story”. Here, the estimator draws a comparison between one user story, and one or more others. Thus if the user story is bigger than the other by two-fold, the estimate it receives is greater than two-fold. This goes on to show that the estimation via relative size is preferred over estimation, via absolute size. Also, in this type of estimation, not all user stories are measured against a single yardstick or a baseline. Rather, a new user story is estimated against those stories, which were already estimated. In short, we refer to this as “triangulation.”
Another form of estimation entails splitting a user story into smaller, easier-to-estimate pieces. This is because if a project intends to include a myriad of user stories, which would take about 4-5 days to develop, then estimating a single user story would entail a considerable amount of time.
It is essential to note that estimating large user stories is not easy: also, finding a similar user story to compare with is another question. Questions such as “Is this user story more difficult than that user story”, differs from questions such as: “Is this user story two times bigger than that user story?”. Given that, splitting or breaking the large user story into smaller items, and then estimating them, would be a more viable approach.
Agile estimation techniques
Agile project estimation can be run using any of the seven 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.
Post discussion, each estimator chooses a single card with the purpose of estimating a user story. Here, if the value offered by all estimators is the same, then that would be considered as the final estimate. On the other hand, in case of different values, the estimators would engage in a discussion, until a consensus is reached.
2) T-shirt sizes
This estimation 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 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 case of a mismatch, a discussion takes place for a consensus, and arriving at the final estimate.
3) Dot voting
This 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.
On the contrary, if the stakeholders are not happy with the order, then a discussion takes place where the user stories are then grouped on the basis of priority, from high to low. The user stories with high priority are then posted on the wall for voting. This is carried out until the final order is achieved, as per the stakeholders’ consensus.
4) The Bucket System
This 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.
In addition, you may change the bucket order, in case there is a difference of opinion in the group. For instance, if the group feels that the first item should belong in bucket 2 and not bucket 20.
Another approach that is used here is “Divide and Conquer.” The remaining items are divided among all the participants, who place the items within the buckets, at their own discretion. Additionally, if a participant is not clear about the product backlog items, or if the other participants are finished placing their user stories on the table, then the other participants can take up the participant’s user stories.
Towards the end, the participants carry out a “sanity” check. A participant can call out to the other participants if an item is placed within a wrong bucket. A discussion then takes place to gain a consensus. The facilitator ensures that no items are moved until a sanity check is performed.
This is another form of the bucket system, a simplified one. Here, participants can place the items in any of the three categories: large, small, and uncertain. “Large” and “small” categories may include the simpler user stories, while the complex ones can be placed under “uncertain.”
Thus this technique is helpful in case the product backlog includes comparable items.
6) Affinity mapping
This 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 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.
7) Ordering method
This technique is helpful in cases where the item numbers are large, and there are fewer people. Here, the product owner prepares a scale – from high to low – and places the items randomly. Next, each participant will move any product backlog item, up (high) or down (low), on the scale, based on priority. This drill goes on until the participants are satisfied with creating the priority order.
Understanding our Agile estimation approach
Here’s an example: a customer (say John Lawson) approached us for getting a CRM developed. (We have used some hypothetical names in the example below to protect the identity of the individuals involved):
John approached us through our Account Manager, Ashima Kapoor. John explained that he ran a startup and was dependent on VC funding for building his product. He listed a few features he wanted to include in the CRM solution and problems he wanted to solve. Though his requirements were not precisely defined, he asked for an estimated budget for the tertiary scope he shared with us.
Ashima then pushed the project into our discovery phase, involving the estimation team of: Anuj Singh from the Mobility team, Arpit Thakur, a technical architect, Bindu Singh from Xamarin, and a few more people from the UX/BA team.
During the discovery phase, our estimation team held regular workshops with John to understand the requirements and define the scope by filling the gaps. Our team then defined the modules and viable features for the application, and a ballpark figure estimate based on the limited scope. Rather than providing a single figure as an estimate, our team split the whole scope into parts, based on levels and numbers of resource engagement.
The representatives provide a monthly cost projection along with an estimated timeframe for the development team to deliver the first release of the application. Since cost projections were estimated on a monthly basis, John was able to approach the investors in a more defined and periodical manner. In addition, he was able to evaluate the monthly payments based on progress of development, instead of paying for all the development in one shot.
Agile has gained popularity for its flexibility, adaptability, and faster time to market for a project; it continues to be questioned for the lack of estimation possibilities. However, Agile estimation is not really that complicated anymore.
In fact, estimation is one of the most critical requirements for a business owner who puts their faith in their technology partner. There is no way a technology partner can avoid it. While there are certain approaches involved in Agile estimation, we have one that has proven effective for us in keeping our clients happy, and confident in our abilities.