Estimation is a hard but crucial activity that agile teams must go through in order to be efficient in planning, managing, and estimating the project. Estimation requires taking into account different factors to have accurate estimates. Scrum guide mentions that estimates should be done by the team members that are going to work on that project, but it does not mention how we should estimate. Therefore, there are multiple techniques to estimate, but estimation with "Story Points" is becoming more and more popular. Here's the main question; if story points estimate also provides the effort (time) required to complete the work, then why not estimate in hours or days directly? To clear out your concerns about the estimate with story points, this article provides conclusive evidence about why story points estimates are more reliable and accurate in the present era.
Before we jump into defining story point estimation and discussing its other working aspects, let's highlight its significance in estimation with the help of a real-world example.
Consider that you live in New York and every day you have to drive 10 miles to reach your office. The time it takes you to reach the office is not the same every day. There are multiple factors that contribute to the time you will spend on the road to reach your office, such as traffic load, weather, time of day, etc. If you have to estimate the time it takes you to reach the office, you have to take into count all the factors that can contribute to the delay while estimating.
In Scrum product backlog, the items also witness similar influential factors that should be considered while estimation. In agile planning, you should consistently and accurately estimate the velocity and time to avoid facing missed deadlines, scope creep, roadblocks, bottlenecks, and similar other project failures. This is where estimates with story points play a helping role, as it offers a more accurate way to estimate time and effort.
Now we know that story point estimation offers more accurate time and effort estimates, let's discuss other well-known estimation techniques and their downsides.
Some teams like to estimate tasks or projects by the hour or day and then using that estimate they set total hours/days per sprint. However, if you evaluate this estimation technique with the above traffic example, then you will realize that such estimations are mostly based on distance from destination, not the other hurdles in between. So, an hour/day-based estimation can become highly inaccurate in unexpected project hurdles or similar other factors.
Some teams also practice the "Ideal Days" estimation technique in which they estimate the days count it would take to complete the task or project if the team worked on it continuously without any interruption. But this technique fails to offer accurate estimates because if developers are working 8 hours a day, then they are also dealing with meetings, emails, chats, and other activities too during those working hours. So, there is no concept of "work without interruption" in the real world.
Story point estimation is becoming more common owing to the accuracy it offers in estimating the time user stories will take to complete. In story point estimation, teams properly consider the complexity and effort to set each product backlog item with a numerical value.
In simple words, story points not just look at the time but consider all the factors to estimate sprint planning. So, the one-sentence definition of story points can be:
“Story point is a point-based relative unit of measure that is used to provide a relative estimate of the efforts required to complete a project.”
In story point estimate, the team does not estimate product backlog items in hours, rather they estimate based on how much effort a particular item demands relative to other items. The three main components of story point estimation include complexity (reflects how complex is to complete that project or feature), risk (reflects the risk associated with the project, unclear demand, dependencies, and other factors), and repetition (reflects the familiarity level of the team for that project or feature and how tedious some tasks are going to be).
When a team estimates with story points and properly considers the above three main components, the estimates are going to be more accurate. In addition, the team's experience with story points over time makes them have more realistic estimated points per sprint. In other words, their gradual experience makes them clearer about how many points they can deliver at this much time frame. For example, a team estimated 57 points in the first sprint but delivered 25 points only. Similarly, it estimated 42 points and 37 points in the second and third sprint but delivered 30 and 25 points respectively. So, when they estimate for the fourth sprint, they can keep in mind their past 25-30 points delivery capability and set the estimation accordingly. In short, story points bring efficiency, consistency, and productive aspects in teams.
By now we have a bigger picture of how story point estimation works and some of its advantages over time and day-based estimations. But let's have a more in-depth look at some of the key reasons that highlight why to estimate with story points:
Estimates with story points trigger consensus-based estimates, as different team members offer different viewpoints about the user stories. One member may present an efficient way of completing a task, while another member may highlight a deeper understanding of the processes involved in completing the task. This way, there is a better discussion environment where team members can share their viewpoints, develop better understanding, reach consensus, and have efficient estimates.
In time-based estimation, you will receive different time estimates from different members because they estimate the time based on their understanding and experience. But story point estimation encourages discussion on efforts and complexity, thereby the consensus is received quickly and efficiently.
Story point estimation encourages an environment of collaboration between product owners and the developing team. Such collaboration results in deeper understanding and discussion for better estimation.
For example, when a team starts the estimation, there will be questions about user stories and other requirements. Such questions let everyone participating in the estimation have a complete understanding. Similarly, when tasks are broken down into smaller sub-tasks and estimated with story points, product owners can effectively prioritize all aspects of the work.
One of the key reasons to estimate with story points is that it removes the deadline hassle. When you estimate based on time, your team have to come up with some deadline, which can create pressure if unexpected problems arise.
On the other hand, story points bring accuracy because they consider all the expected and unexpected scenarios and do not emphasize strict deadlines. In fact, there is no such thing as a deadline in most story point estimates, as the focus is more on prioritizing tasks and completing them efficiently.
Story point estimation brings the confidence, commitment, and productivity aspects to your team. When they have a proper understanding of tasks and confidence that they can accomplish the goals, they show more commitment to work. They know where they are headed, what are the prioritized task, and what are the expectations.
In time-based estimation, teams do have to list of tasks to complete, but the pressure of deadlines and fear of unexpected problems impact their productivity and commitment to work.
As narrated by other points, story point estimates provide a more accurate estimation of product backlogs. It does not make the team to commit doing this amount of work in this much time. Rather it just provides the estimate of doing work on a prioritized basis.
Accuracy in estimation means clear objectives and timely releases. The team conducts the estimates of user stories, plans the sprint, and starts the work.
Another cool aspect of story point estimation is that it lets teams adapt their workload according to the situation. For example, if a team member joins another team or you add a new member, you can quickly adjust your velocity.
In simple words, you can quickly adjust the number of stories you are able to complete in a sprint depending on the present situation. Since there is no artificial deadline to meet, the team is more adaptable with story point estimation.
It is difficult to fulfill all the expected outcomes in a release when the tasks are time-consuming and complex. However, story point estimates assist your team to pick up few smaller stories to fill out your capacity during every release or sprint.
In addition, story points also let you increase the team's capacity rather than asking them to work extended hours. For example, while having an estimation session, you can look for ways to reduce effort, mitigate risks, and develop a team of skilled members that can handle the complex task efficiently. This way, you will be able to increase the team's capacity, productivity, and efficiency.
When teams are estimating in days, they have to take the discussion deeper to properly estimate the days it would take to complete the task. Here again, the pressure of commitment and delivery at deadline impacts the discussion process and causes teams to spend more time and energy to estimate rightly.
However, story points offer much faster estimations. For example, team members are first presented with the user story, then they engage in collaborative discussion, present their points, and reach consensus without any time commitment. So, the whole process is much faster and lets teams spend their time and energy on other important tasks.
Now that we know what is story point estimation and how it outclasses other estimation techniques, let's divert our focus on discussing the best way to estimate story points.
There are different ways to estimate story points, such as Planning Poker, T-Shirt Size, Dot Vote, The Bucket System, Affinity Estimation, and similar others. But one of the most commonly adopted approaches to estimate story points is "Planning Poker".
In the Planning Poker estimation technique, story points are used to estimate the difficulty of the product backlogs. It is a consensus-based technique where story point values (Fibonacci sequence) are assigned to represent the complexity level.
Planning Poker begins when a team sits for an estimation session. The moderator reads out the user story and discusses it with the team. After discussion, each team member will pick the card with a story point that he/she thinks best suits the user story. Once everyone has provided their estimates and the estimations match up, then that's the final estimate. But, if there is a major difference, then further discussion is carried out until a final consensus is reached. This way, the Planning Poker technique helps teams to efficiently estimate with story points.
The major drawback with Planning Poker is that it demands team members to be present for the session all at once. In addition, they have to understand the user story and provide an estimate right away. In the present pandemic situation and evolvement of remote working, conducting Planning Poker sessions seem challenging. This is where the "Async Planning Poker" technique comes to the rescue.
In Asynchronous Planning Poker, the moderator sends the user stories to the team members via email or other methods along with the deadline by which they have to deliver the estimate. Team members can understand and estimate user stories at their own pace and suited time while ensuring that estimates are sent back before the deadline. Once the moderator receives all the estimates and there are not many differences in estimates, then the final estimate is informed to the team members. However, if there are some differences, then the team can have a quick session (remotely) to discuss the mismatches and reach a consensus. In short, Async Planning Poker is an advanced form of Planning Poker and best suits remote and distributed teams.
Story point estimation offers better collaboration and understanding of product backlog. The estimates are more accurate and trustworthy. In addition, since there is no influence of time on estimates, the team feels less stressed and well-planned to address unexpected situations.
If you are also looking to adopt story point estimation in your organization or team, the Async Planning Poker technique seems a perfect start for you. But you also need an app that can let you and your team do async estimates effectively. Async Poker – Remote Planning & Estimation offers the best user interface, feature-rich functionality, and convenient way to conduct story point estimates via the Async Planning Poker technique.
