Engineering Estimates

Learn about story point estimation, the problems it solves compared to time-based estimation, and how best to implement it with your team.

Estimating engineering work is a very complex task. Most teams find it hard to accurately estimate development effort as there are a lot of things that need to be factored in. For example, a senior developer might complete a task in two days, while a junior or intermediate developer might need four to ten days for the same task. Further, if a senior developer is busy with meetings or waiting for third-party integrations, a task that would normally take two days might easily require four. Estimates are such a contentious topic that some agile leaders and coaches, proponents of the #NoEstimates Movement, advocate for abandoning them entirely.

Engineering work is traditionally estimated by looking at the time required to complete a task. However, this method does not consider the task’s wider context—for example, varying team skill levels, unscheduled meetings, unclear requirements, waiting on integrations, changing objectives, and so on. As a result, time estimation leads to an increased risk of missed deadlines, task bottlenecks, and scope creep.

Story point estimation, on the other hand, is an estimation technique that instead looks at the effort required. In story point estimation, instead of time, each user story (work item) is assigned a number (points) representing the effort required to complete it. The actual time required to complete the user story is not known during estimation; this makes it easier to deal with complexities, risks, and unknowns that might arise.

In this article, you will learn about story point estimation, the problems it solves compared to time-based estimation, and how best to implement it with your team.

Benefits of Story Points

Story point estimation is a holistic approach to task estimation. Rather than focusing on the time taken, which might differ from developer to developer, story points look at the effort required to complete a particular task. With story points, the team assigns points to a backlog item relative to the required effort, its complexity, and any risks or uncertainties.

This approach has the following benefits:

• More easily identify the required effort: Since point estimates are independent of the time it takes to complete a task, team members can more easily agree on the effort required for a particular sprint item.
• Accommodates different skill levels in your team: Unlike time estimates, story points show a clear measure of the effort required for a particular task, making it easier to assign resources to tasks. Senior developers can take on higher-point tasks, while junior developers take lower-point tasks.
• Helps measure the team’s sprint velocity: A team’s sprint velocity measures how much work a team can accomplish during a single sprint. This is useful when assigning work to complete during a particular sprint and also for gauging team productivity. By using story points, you can easily calculate your team’s average velocity by looking at the total number of story points they complete each sprint. The more points your team can complete without becoming burned out, the more productive they are.
• Build consensus and eliminate gray areas: When using story points, a whole team has to agree on estimates, which helps to ensure requirements are properly understood and eliminate incomplete information. This agreement is achieved through a process known as planning poker, which is explained later in the article.
• It’s a faster way of estimating work: Story point estimation reduces the time taken to estimate work. This is because this estimation technique assigns points to a work item relative to other work items, so as you complete more tasks, it becomes faster and easier to estimate the effort required for new tasks.

While story points can simplify and improve the estimation of tasks, some critics have highlighted the following drawbacks:

• Difficult transition: Transitioning to story point estimation might be hard for teams that are used to estimating tasks using time (i.e., hours, days, and weeks).
• Need to account for time spent: Ultimately, story point value needs to be converted to time for project-planning purposes, which is sometimes challenging. Project managers have to use sprint velocity to estimate time spent per story point.
• No standardization: Story points are not standardized—there is no set value for one story point, and the values may differ from team to team. This means that story point baselines and estimations are different in each team, making it difficult to compare velocities between different teams.

Understanding Story Points

To properly estimate a given task using story points, the team will review the task and assign it a story point based on three factors:

• Effort: This is how much work will be required to complete the task. This effort is independent of a developer’s skill level or experience. Instead, a team establishes a baseline—for instance, adding a button is one story point, and then subsequent tasks are assigned points relative to that task.

• Complexity: This is how complex the given task is. The task will be assigned more points depending on how complex it is or how many dependencies or integrations it has.

• Unknowns: A key hallmark of agile is being adaptable enough to work with changing requirements. This means sometimes you have to estimate work before all the requirements are clear. Story point estimation takes this into account and assigns more points to tasks with more uncertainties.

Story Point Estimation with Fibonacci Numbers

Story points are a relative estimation tool—they estimate work relative to other work items. To achieve this, story points use the Fibonacci sequence to assign points. This means that when assigning points, we do not assign any linear number but instead use numbers from the Fibonacci sequence. The Fibonacci sequence is a mathematical number sequence developed by Leonardo Bonacci, where each new number is the sum of the two previous numbers—that is, 0, 1, 1, 2, 3, 5, 8, 13, 21, and so on.

The Fibonacci sequence is used instead of the normal number sequence (1, 2, 3, 4, 5, 6, 7, etc.) because its numbers increase relatively, and that makes for easier estimation. The nonlinear increase makes it easier to make a distinction between two estimates. Consider this—on a scale of 1 to 20, telling the difference between a 12 and a 13 might be hard, but since Fibonacci numbers increase proportionally in the sequence, it’s easier to tell the difference between a 13 and a 21.

The image below of the Fibonacci spiral demonstrates this concept. The squares representing the Fibonacci series increase more and more, and their differences become more apparent, making estimation easier.

Other estimation techniques such as T-shirt sizes and the bucket system also use this relative differences in size for more accurate engineering estimates.

Establishing a Baseline

The key to implementing story points is to establish a point baseline. This means having sample tasks that correspond to each point according to our Fibonacci sequence:

• 1 point: A copy change

• 2 points: Adding on-page analytics

• 3 points: Adding a new entity with CRUD functionality

• 5 points: Implementing a feedback form

• 8 points: Implementing a live-chat feature

Having a baseline makes it easier for the team to compare work items and assign them points. As you can see, an increase in points also means an increase in the complexity and effort required for the corresponding item. This baseline will guide us when assigning new work items a story point. The use of Fibonacci numbers on the story points makes it easier to differentiate the effort required—for instance, an 8 story point item vs. a 13 story point item.

Do not worry, however, about making this baseline perfect. It can always be reviewed and altered as the team gets more comfortable with estimating tasks using story points.

Planning Poker

Planning poker is an agile activity usually held during a refinement or sprint-planning meeting. During this activity, the team reaches a consensus on story point estimates for tasks in their sprint backlog.

A backlog item is presented, and the team is free to ask clarifying questions to understand the scope of the task. Team members are then handed cards depicting the Fibonacci sequence and asked to assign story points to the backlog item. If the cards show the same points, that point is assigned to the item, and the next backlog item is discussed. If not, team members discuss their different views until a consensus is reached.

Sharing different points of view helps identify any assumptions or areas that require further clarification. During this process, the team should be on the lookout for huge differences in story point estimates, as this might mean a backlog item is not well understood or has too many unknowns.

Setting a maximum threshold is another good practice here: this is the maximum number of points a task may have. If you set your threshold to 21, it means no tasks should be assigned more than 21 points. If a task goes above that threshold, it means you need to break it down further into smaller tasks. This helps identify huge workloads that might potentially cause bottlenecks or be stuck in WIP for the whole sprint.

Review and Adapt

As with any activities in agile, the story point estimation requires constant review and adjustments. This is ideally done during the sprint retrospective. Using story point estimation, you can easily identify the team’s sprint velocity, which is the number of points a team can complete during a sprint. This number varies per team depending on skill sets, the number of resources, and how well the team works together. While it’s always ideal to try and improve this number and thus productivity, the ideal velocity is one in which the team can complete required work items without incurring burnout, feeling overworked, or pressed for time.

The sprint retrospective, a review meeting held after every sprint, is also an ideal time to review your story point baseline. After your first sprint or two, the engineering team will have a clearer idea of how much effort and work each task requires.

Conclusion

Estimating engineering work is a complex but crucial part of ensuring your project’s success. Story point estimation provides improved estimation by looking at the effort required to complete a particular work item rather than using the traditional approach of estimating work based on time, which can be unreliable.

It considers the complexity of the task, as well as any unclear requirements. Using this method, the team must establish a consensus to assign points to a particular task based on the Fibonacci sequence, which measures the complexity of tasks relative to each other. It also makes for faster and easier estimates and over time helps you determine your sprint velocity. This will eventually lead to more accurate estimates tailored to your team and their productivity.

Agile tools like Status Hero can help you implement story points within your team and provide more accurate estimates. Status Hero is a work communication tool that simplifies your project management by removing time-consuming status-update meetings and other interruptions from your workflow, replacing them with real-time reports. Status Hero also integrates into all your favorite tools like Jira, Slack, Github, Asana and more, collecting data and gathering unique insights into the team’s productivity, accomplishments, blockers, and mood. This data can be very useful in sprint retrospectives and planning poker events, which are core to producing solid agile estimates.

By Michael Nyamande. A Digital Product Manager by day, Michael is a tech enthusiast who is always tinkering with different technologies. From web and mobile frameworks to NoCode development, and recently blockchain development, he believes in the problem-solving power of technology.