Are you looking for new ways to approach estimation in Agile? In this article, we’ll explore alternative approaches to traditional Agile estimation techniques like story points. From relative estimation and lean planning, to Monte Carlo methods and the #noestimates movement, we’ll cover a variety of options that can suit different teams and projects. Let’s discover new ways to approach estimation in the world of Agile!
In these two articles, I’ll go through the following estimating methods:
- Story Points
- Use Case Points
- Relative Estimation
- The #noestimates movement
- Monte Carlo methods
In Agile development, accurately estimating resources and time needed to complete tasks can be challenging. The traditional approach of detailed upfront planning and forecasting may not be feasible in fast-paced and iterative projects, but overly rough or optimistic forecasts can lead to unrealistic expectations and project failures. To balance accuracy and speed, teams must find alternative approaches that take into account the uncertainty and complexity of their projects.
1. How do I estimate Story Points in Agile?
What are story points?
One popular approach in Agile is using story points, a unitless measure of effort used to estimate the complexity of tasks. They were first introduced in Extreme Programming (XP) and are favored in Agile for their simplicity, flexibility, and bias reduction.
Story points are easy to use and compare, as teams can focus on comparing tasks to each other. They can be used to estimate tasks of any size and can be adjusted to fit the needs and preferences of each team.
This method can help reduce bias by focusing on the relative complexity of the task, improving the accuracy and reliability of estimates. However, like any estimation method, story points have their limitations – it’s important to avoid common mistakes when using story points. We’ll share some examples later in this article.
A example of Agile Story Points in the real world
Imagine that a software development team is working on a project to build a new online shopping platform. The team is using an Agile methodology like XP or Scrum and has identified a number of user stories that need to be implemented in order to deliver the desired functionality to their users. The team decides to use story points to estimate the effort and complexity of each user story.
Poker planning cards
To begin, the team defines a scale for their story points. They decide to use planning poker and the Fibonacci sequence of 1 to 13, with 1 being the least complex and 13 being the most complex. Although you can see bigger numbers in the picture, in my experience, anything beyond 13 is too big and requires more splitting. More modern card decks have other symbols like a coffee cup to ask for a rest.
Here are a few examples of how the team might use story points to estimate the user stories:
- “As a shopper, I want to search for products by keyword so that I can quickly find what I’m looking for.” The team considers this user story is a “2” because it involves building a basic search functionality that is not particularly difficult to implement.
- “As a shopper, I want to filter my search results by price, brand, and other criteria so that I can find the most relevant products.” The team assigns a “3” because it involves building more advanced search functionality that will require more effort to implement.
- “As a shopper, I want to customize my shopping experience by setting preferences for the types of products I’m interested in and the brands I prefer.” Some team members say it’s a “5” and others claim it’s more difficult. After sharing their arguments, there is a consensus that the story is estimated as an “8” because it involves building a more personalized shopping experience that will require a significant amount of effort to implement and involves redesigning the UI.
How do I estimate Story Points in Taiga?
In Taiga, there is a section to add story points to your user story. The graph on the top of the Backlog page shows the burndown rate of the user story points- you can easily keep track of the optimal points per sprint and the real points per sprint. Note that the graph takes 100 project points as the reference, you can change it in the Settings >> Project >> Project Details >> Number of US points. You can also add new user story points in Settings >> Attributes >> Points >> Add New Point.
Story points allow teams to estimate the effort and complexity of user stories, prioritize them, and track progress. Though, my preferred benefit here is the opportunity for team members to discuss and compare their approaches to implementation.
What to take into account when using Story Points
Despite their popularity, story points have a number of limitations that can impact their effectiveness. Some of the main limitations of this method include:
- Lack of accuracy: Because this method is based on the relative difficulty of tasks, rather than on the amount of time or resources required to complete them, they can be imprecise and subject to interpretation. This can make it difficult to accurately compare tasks or to use them as a basis for planning and forecasting.
- Calibration issues: Story points are often assigned using methods such “planning poker” or “fist to five”, which can introduce bias and inconsistency into the process. Teams may also have different ways of assigning these points, which can make it difficult to compare estimates across projects or teams.
- Subjectivity: Because these points are based on individual judgment, it can be influenced by personal biases, assumptions, and preferences. This can be particularly problematic when teams are working on tasks that are complex, novel, or uncertain.
- Communication difficulties: Story points can be difficult to communicate to stakeholders or customers, who may not be familiar with this unitless measure of effort. This can make it challenging to explain or justify estimates, or to use them as a basis for negotiation or decision-making.
Taiga partially addresses these concerns by allowing a team to specify a breakdown of story points based on the different roles or skills involved in a user story. For example, a user story might be 3 points for frontend development work and 1 point for design work, making it a total of 4, thus increasing accuracy and reducing subjectivity. You can decide which team roles are allowed to have story points estimation input visiting Settings >> Permissions. This breakdown is then shown across the project.
We already mentioned some of these concerns in the previous article I dedicated to The Burn-up Chart. Overall, while this method can be a useful tool for estimation, it is important to be aware of its limitations.
Next up, I’ll go through some other estimation approaches. But first, do you use story points? Do they work for you and your team? If you use any other method, which one is it?
