The Story Point Controversy

Estimating agile work has been debated in organizations for years. There are several estimation techniques, but story points, in particular, can be a mystery to many. Although it is a commonly used method, some may argue its effectiveness. This article describes the purpose of story points and why they can be controversial. 

What is a Story Point?

A story point is a unit of measurement for a user story based on factors such as complexity, effort, uncertainty, and risk. Story points can be used in agile methodologies like scrum during sprint planning by assigning a point value to a user story. Story pointing is a quick way to estimate work using tools like Planning Poker or the Fibonacci model. For example, the team may assign a 1 or a 2 to a story they consider low effort. The intent is to help scrum teams have an open dialogue to gain a shared understanding of the work relative to all user stories in the product backlog. 

The whole team (those doing the work) discusses the pieces and components involved with developing the user story and arrives at a consensus on the story point estimate. Some teams establish an agreed-upon baseline for the lowest effort story with the lowest story point. If a user story has a high number of points, then the team breaks down the story into smaller stories and estimates them. 

How Story Points Are Used in Sprints

Once sprint planning is complete and the team has decided what they can commit to in the sprint, they now have their total committed number of story points. By the end of the sprint, the team will have burned down all story points that meet their Definition of Done. Any stories that are not complete are either moved to the backlog, perhaps further refined and re-estimated, or moved to the next sprint -- this is a team decision. 

The team repeats this process for every sprint. Over time, they develop their velocity, which is an average of the total number of story points completed at the end of each sprint. The completed story points can vary each sprint given the team’s capacity (available time for each sprint). Factors that could impact capacity include the number of team members working in the sprint due to personal time off or illness, attending training or conferences, unforeseen events, external distractions, or perhaps it is a meeting-heavy sprint (consider department or organizational meetings). 

Why Story Points Can Be Controversial

Because story points are a nebulous, arbitrary value, some organizations may not understand the actual unit of measurement of user stories. They may misconstrue their purpose altogether, and it is difficult to consistently equate story points to delivery time. Let's take velocity, for example; this is considered a key metric in agile, but it can be misused when measuring a team's productivity. Leadership may ask about the team's velocity and want to know how many story points they burn down each sprint. This mindset of velocity as a productivity metric using story points does not give a good picture of productivity or the time it will take the team to deliver a feature. 

Let's say the team takes on and completes 20 story points in sprint 1. In sprint 2, they plan for 40 story points but only complete 30 points. In sprint 3, they take on and complete 30 story points. It does not mean that the team is more or less productive from sprint to sprint. Instead, this is part of the planning process for the team to determine what they can commit to each sprint given their experience from the last sprint. Because user stories have varying degrees of complexity and uncertainty, the team may have learned that their estimates during sprint planning were too high or too low and adjust accordingly with each sprint. Team capacity is another consideration of why story points may fluctuate. Perhaps they couldn’t complete as many as they planned due to an illness on the team or some other unexpected event. 

Story points are also misused as a metric to compare one team to another. Team A may be averaging 40 story points while Team B may be averaging 80 story points. Leadership may misinterpret this to mean Team A is twice as productive as Team B. No two teams are created equal. They may have varying skill sets, team size, and different definitions of a story point. Comparing teams harms their estimating process, creates inflated estimates, and demoralizes the team.

Finding a Balance

It’s understandable that organizations need to know how productive teams are and require something tangible to measure their performance. However, it’s a misconception to assume that story points and velocity are productivity evaluation metrics. Story points are used by the scrum team for planning purposes and should not be considered a unit of productivity by leadership. Velocity as a metric should be used by the scrum team as a data point to help them with their decision-making for sprint commitments. 

The team’s continued learnings and experience affords them the potential to improve their estimates over time. Through inspection and adaptation, they become more predictive and able to forecast feature releases. What matters in agile is open and productive dialog about the work, making progress towards the product goal, and frequently delivering value to customers. 

--

Please subscribe to stay informed with the latest agile and scrum articles written by experienced practitioners.