Complete Guide on How to Get the Estimation Right for Acing Your Agile Projects

Recently, I delivered a web application development project for counter wildlife trafficking initiatives under a leading NGO. By utilizing the most reliable agile estimation technique i.e. story point technique, we (team) realized that our estimations were more accurate in this case in comparison to the other projects where the man-hours estimation approach was used.

Through this blog I would walk you through the journey and explain necessary steps required to mitigate the causes of incorrect estimates which revolves around answering some of the very important questions and principles like - the need an estimation, different agile estimation techniques, implementing these techniques, and benefits of using story points over the man-hours approach?

This blog will focus on every question mentioned above to save you from the mishap during project delivery.

Why would you need an estimation?

“The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them” —Steve McConnell

There are two major reasons why we need estimation-

1. According to a 2017 report from the Project Management Institute (PMI), almost 28% of the projects fail due to the incorrect estimates which leads to poor planning. Incorrect estimates are majorly due to:
   
   1. Lack of awareness about estimation
   2. Poor execution of estimation techniques
2. As a Business Analyst or Product Owner, whenever you propose a solution to the client, the very first question you should raise is, “What will it cost?” or “How long will it take?". To respond, you need to have a fair idea about the development effort of the solution. It is very crucial to do an accurate estimation to:
   1. Avoid project failures
   2. Set realistic expectations with the client

Source: agilenutshell

The principles of Agile Estimation

There are 3 principles of agile estimation-

1. Rapid

Unlike traditional software development, the agile methodology enables fast and dynamic software delivery mechanisms where we are more focused on the end working software. Despite the fact that estimation is important, we can’t sell the estimates to our client, hence it is considered waste. 

To overcome this, we need to do estimations fast.

2.  Relative

In agile estimation, we don’t directly estimate the dollars and man-hours/days to deliver a project. Instead, we focus on estimation using relative units. We use points or even qualitative labels that can help us to simply compare the items we are estimating to each other.

3. Collaborative

All agile estimation techniques are collaborative, i.e. while doing the estimation, everyone should be included in the estimation process. It helps to keep the team sport alive. Every team member contributes a different viewpoint to accomplish any user story. 

The different agile estimation techniques? 

While we generally keep hearing about planning poker for an agile estimation, there are other agile estimation techniques too-

1. Planning Poker
2. The Bucket System
3. Dot Voting
4. Affinity Mapping
5. Ordering Method

With efforts being directly proportional to the complexity, it becomes relatively difficult to estimate as to when complexity is high, which otherwise would have been easier another way round”

To execute the estimation, we use the following two techniques majorly, i.e.

1. Story Pointing

A story point is a conceptual measure of how much effort is required to implement a user story. It is an abstract number that conveys the difficulty level of the user story. The difficulty is associated with complexities, risks, and types of efforts involved. 

Broadly, we use below three scales for sizing-

1. Relative Numeric Sizing | 1, 2, 4, 8, 16
2. Fibonacci Sequence | 1, 1, 2, 3, 5, 8, 13, 21
3. T-Shirt Sizing
   
   

2.  T-Shirt Sizing Approach | XS, S, M, L and XL

Unlike traditional times when teams used time format (days, weeks, & month) for estimation, many organizations have moved already towards the story point estimation representing the relative effort of work in a Fibonacci-like format: 0, 1, 2, 3, 5, 8, 13, 21. 

Source : rubygarage

How to implement these techniques?

When we estimate with story points, we assign a point value to each user story. These values should be relative values based on the relative principle. Any raw number assigned to a user story won't matter unless it is not relative to another user story. To keep the estimates simple-

• We define a baseline story that isn’t necessarily the smallest, but it is something that every team member can resonate with for example – user login.
• We align the baseline story with 2 story points and further align relative values to other user stories keeping in mind the complexity, risks, and avoiding repetition. 

The story points are estimated based on several factors as shown in the picture below:

Source: tothenew

The rule states that "If a story is assigned 2 story points then, it should be twice as much as a story that is assigned 1 story point considering the complexities and efforts involved. And at the same time, the user story with 2 story points should be 2/3rds of the story that will be estimated with 3 story points".

Now, let me take an example from my recent wildlife project where we decided to adopt the agile estimation techniques and hence, followed the principles of agile estimation. 

In this project the whole scrum team including 2 developers, 1 designer, 1 tester, 1 BA took part in the estimation exercise of product backlog items. Unlike other projects where estimates were provided by the senior stakeholders and other teams, here we as a team collaborated and shared the estimates. Like in one of the situations where a wildlife species searches on 2 new browsers had to be implemented. It was a 1-point development effort, but it required a lot more effort from a testing perspective. We realized that every team member brings up a different perspective on the table while estimating the backlog items. Thus, this project was a huge success for us, and we delivered it within the deadlines. 

The below picture gives more clarity on how we arrive from the user story points to task-based estimation in man-hours. Mostly, we come to know about the team velocity after the first sprint.

Source: agilebuddha

Benefits of using story points over the man-hours approach

In our earlier projects, we used to understand the high-level requirements from the client, segregate them into high-level modules to chalk out a solution and derive the estimates based on guess estimates and previous experiences. We used to share the high-level estimates with client after discussion with internal stakeholders which landed us into issues like,

• Scope creep
• Late deliveries
• Setting unrealistic expectations

With the industry focus moving to agile, people are upgrading towards agile but somehow there is a lack of awareness about these new techniques, people confuse the story point estimates with estimation in hours. 

A story point, being a high-level conceptual measure of complexity and efforts, the hour-based estimation, on the other hand, is a low-level measure to calculate the actual effort in man-hours. Agile estimation techniques help us to tackle the problems of man-hour based approach and further benefits the team to: 

• Handle complex scenarios with ease
• Keeping alive the team sport
• Enable the team to understand the complexity and risks associated with a story
• Understand their capacity and generate better estimates – Picking up items as per our team velocity
• Avoid blame game within the team

Conclusion

This is generally how we do the story points estimation. Both the story points and hours estimates are targeted to serve different goals in an agile project, and we should not confuse the two. 

Also, in my next article, I will cover more about other estimation techniques, MVP and other related topics. Stay tuned!