Many organizations today rely on using story points for velocity estimation. Each user story is assigned story points, which leads to an estimation of how many user stories can be completed in a cycle.
While teams’ use of story points helps understand team capacity and pace, there are known challenges to this approach. A few questions have been uncovered — do story points accurately measure task complexity? Should product and engineering leaders continue to rely on story points to understand and predict team velocity?
In this piece, we will learn about story points and how they can be used for velocity estimation. We will also look into the benefits and pitfalls of story points for velocity estimation and a few best practices to achieve desired results.
In agile project management, story points are a unit of measurement used to estimate how much effort or work is required to complete a given task (user story) in the product backlog.
Story points have become more accepted in recent years and are adopted by many product teams worldwide. They require team members to dig deeper into the task requirements and determine what’s needed to complete a user story.
Let’s look at two examples:
34By definition, user story 2 involves more effort to complete the task and is therefore assigned more story points. The higher the estimated effort required, the higher the number of story points.
By defining story points, product teams can estimate velocity and project the quantity of work that can be completed within the specific 2–4 week period known as sprint or cycle.
For instance, if two engineers complete a total of 52 story points in the last three cycles, then the average velocity is calculated as 52 / 3 = 17.3. This means in the fourth cycle, a team of two engineers should complete approximately 17 story points.
There are three ways to size user stories.
The first is a linear sequence. This describes a linear progression of numbers and is typically 1, 2, 3, 4, and 5, where you simply add 1 to the preceding digit to get the next digit. Pretty easy!
This type of story point sizing can be a little tricky because the difference between one story point and the next is minimal. It is sometimes difficult for teams to agree on what user story has 3 story points vs. 4, for example.
Next is the Fibonacci sequence. In this sequence, each number is the sum of the previous two numbers, starting with 0 and 1. The Fibonacci series is 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…
Unlike the linear sequence, there is a larger difference between each number as you go further in the sequence. Ideally, using the Fibonacci series, the story point estimate should be much more obvious to the team, since one story point could be almost 2x the other, and there is less need for disagreement.
Lastly, we have T-shirt sizes. The t-shirt sizing method is also used to estimate the effort required to work on a user story. With T-shirt size estimation, the options include XS, S, M, L, XL, and XXL, as you have for an actual T-shirt.
Tasks assigned as XS indicate the least effort required, while those assigned XXL indicate significant work.
As described above, there are three ways you can size user stories: linear sequence, Fibonacci sequence, and using T-shirt sizes.
The first step when using story points to estimate velocity is determining which sizing technique works better for your team. While all sizing types could achieve the intended purpose, some team members may have a preference or experience with using a particular type. It is a good idea for product owners, product managers, and engineers to collaborate on this decision so that it is adopted widely without friction.
The next step is to agree on what each size is. For example, using the T-shirt sizes, an XS could mean only design changes required, while an L represents minimal adjustments to an existing user flow.
Agreeing on the size definition is essential to empower team members to assign story points to user stories and agree quickly on the estimation. The size representation should be documented for reference.
The third step is to create your user stories if you haven’t already. The user story should be clear and actionable. It is a good practice to include why the functionality is important when writing the user story, as this information could be useful in determining the solution approach and hence, the story point estimation.
Who is responsible for assigning the story point size to the user story? It is different for each team, but an engineer should take on this responsibility.
Some teams might have an engineering manager or tech lead to take on the primary responsibility of breaking down user stories into smaller tasks. They are, therefore, responsible for including story point estimates. However, with other teams, any engineer within it can take on the role of assigning story point estimates. Typically, the engineer who assigns the story points will implement the task requirements.
Discuss with your team to determine the best option, and be sure to consider team size, responsibilities, and existing processes.
After a couple of tasks have been completed across several cycles, consider tracking velocity over time. How many story points were completed on average? Calculate the average and review progress and challenges as you prepare for future cycles.
There are several benefits to using story points. We’ll go over a few below.
Story point estimation is typically done independently of the task owner (the individual contributor responsible for implementing the user story). If a user story is assigned 4 story points, it is because, objectively, the task requires a certain amount of work to get it done.
This is a better approach than the task owner sharing how long it would take them to complete the task.
It also helps product owners and product managers understand the complexity involved when working on a task. Sometimes, product managers could underestimate the effort required, but having a story point estimation helps the product manager better understand how engineers intend to approach the work and some of the technical debt required to complete the task.
Determining story points is also helpful for task prioritization. The overall effort required to complete an initiative or customer request plays a significant role in determining whether to push forward with the implementation or keep the task in the product backlog in the short term. Without the story point estimation, the product manager may not be fully equipped to make the right decision.
Tracking velocity also helps product teams plan future cycles better. If the team completes an average of 32 story points in a cycle, the product manager or product owner can use this data point to plan user stories for the next sprint, as well as precisely communicate upcoming feature releases.
Having a target goal (in this case, the number of story points to complete in a cycle) could be a good driving force for teams. Team members could easily commit to deliverables and work towards achieving them. For great product teams, there is also a healthy culture of tracking velocity to improve it over time.
Though story points are a great way to estimate velocity, there are also some pitfalls to be aware of when going in.
Relying on story point estimation to track team velocity can sometimes be misleading. It does not consider the nuances that may occur during the cycle, such as a new team member joining the team and having to learn the code base or any further exploration that needs to be done after picking up the task.
Velocity estimation is sometimes used as a data point to micromanage team members. Management could take this estimate as an opportunity to closely monitor the product team’s output to ensure enough work is completed for each cycle and question the team when they feel less work is done.
This can lead to a blame culture and can unintentionally demotivate team members.
Although a key benefit of story point estimation is the ability to estimate the effort required without a specific time commitment, adding story points could still lead to internal pressure and burnout.
A team member could feel unnecessary pressure to complete a task with 3 story points in a few days because that is the general expectation, therefore leaving less room for creativity.
Also, being under such pressure could lead the team member to inflate the story points for future user stories, leading to inaccurate velocity estimation.
Although using story points for estimation is becoming more popular, it is essential to evaluate if it is suitable for your team and how to best measure and track velocity without sacrificing quality work and team efficiency.
If you choose to implement story point estimates, here are a few guidelines:
Create a speak-up culture where engineers genuinely believe that they can share any concerns they have during the cycle and make necessary adjustments to the story estimate.
Avoid comparison — comparison kills creativity! This is especially important for organizations with several teams with different focus areas. The velocity estimate for one team should not be used as a measurement of another team’s productivity because team dynamics and focus areas are different.
Focus on team motivation and personal development. If team members are incentivized to work better, they will work efficiently without a measuring scale. Company leaders should keep the team motivated to deliver their best and achieve key company OKRs.
In this article, we learned the definition of story points and how product teams use them for velocity estimation. We also discussed the benefits and challenges of relying on story points to understand team velocity, as well as a few best practices.
Product teams and leaders must recognize the challenges that come with relying on story points for team velocity estimation and address these issues for better team success.
Feel free to drop a comment and let us know how your team handles challenges with using story points for velocity estimation.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Aditi Jain discusses listening to your consumers’ emotional needs and using that to create an experience that goes beyond just transactional.
By focusing on how a product can solve problems or enhance the customer’s life, you create more compelling and relatable value propositions.
Dane Molter shares how he pushes his teams to adopt a business mindset and to think about the broader portfolio and overall business impact.
A product platform is a shared set of technology, procedures, and components that allows the development of a set of related products.
Learn more →
