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.
“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-
There are 3 principles of agile estimation-
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.
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.
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.
While we generally keep hearing about planning poker for an agile estimation, there are other agile estimation techniques too-
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.
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-
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.
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-
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.
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,
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:
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!