Professional Documents
Culture Documents
What Is Story Point Estimation On An Agile Team
What Is Story Point Estimation On An Agile Team
A R T I C L E | S C R U M F U N D A M E N TA L S
What Is Story
Point Estimation?
Spark conversations about the
effort of product backlog items
BY SCRUM ALLIANCE
( H T T P S : / / W W W. S C R U M A L L I A N C E . O
US)
SEUs My SEUs
0.25
_____ 0.25
_____
available
20
(https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fresources.scrumalliance.org%2FArticle%2Fstory-point-
estimation&title=What+Is+Story+Point+Estimation%3F&summary=Story+point+estimation+is+the+process+of+assigning+story+points+to+a+product+backlog+item
(https://twitter.com/intent/tweet?text=https%3A%2F%2Fresources.scrumalliance.org%2FArticle%2Fstory-point-estimation)
(https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fresources.scrumalliance.org%2FArticle%2Fstory-point-estimation)
Story point estimation is the process of assigning story points to a product backlog item or a user story. Story points are a measurement for understanding the effort
it will take to fully implement a product backlog item or user story.
A seemingly simple technique, estimation in general and story points in particular can feel abstract and frustrating in practice. To some agilists, they’re controversial
(/Article/story-point-controversy) for their tendency to get misused as a way to put performance pressure on a team or compare teams.
However, with a little practice and patience, you and your scrum teammates can fine-tune a lightweight pointing process to understand the scope of the work you’re
planning to do in a sprint. One way you can do this is with story point estimation.
Terms to Know
Developers: Although this term sounds technology-oriented, developers are the people on the scrum team who create usable
increments every sprint from a variety of industries involving complex work. It is considered an accountability distinct from the
product owner or scrum master.
Sprint: The scrum event that contains all other events. During a sprint, the scrum team commits to a sprint goal
(/Article/sprint-goal) and completes work to achieve that goal. Sprints occur consecutively, one after the other. There is no
gap between sprints.
Story point estimation (/Webinar/estimation-and-story-points) helps developers understand whether they’re undertaking an extreme effort, a light effort, or an effort
more or less equal to what they’ve historically implemented in their sprints.
Story points also provide a metric known as velocity (/Article/scrum-team-velocity-formula), which is the number of points implemented per sprint. The scrum team
can use this metric internally to discuss what factors may be causing their velocity to rise or fall over time. Velocity should not be used by management or outside of
the team to compare scrum teams or ask for constant upward velocity, which leads to burnout and a tendency to point PBIs as high as possible to show growth.
Using story points or estimates that are not related to time provides a shared understanding and agreement of the effort of the work regardless of which members of
the team contribute to its completion.
When a team says something like “one hour is equal to three story points,” the equivalency assumes that all members of the team will perform the same work in the
same amount of time. That’s often not the case. While a senior team member may take an hour on a PBI, it may take a junior team member three times as long;
however,
(htt // they’ll be undertaking
lli ) the same effort. Discussing effort instead of hours supports a common understanding of the scope of the work.
Pointing a story in terms of time alone is mostly an estimation of how long a PBI will take a particular individual. At that point, it’s not a holistic and universal
estimation of scope.
As part of a discussion of the effort involved, the developers may factor in the following:
While the variables above are the most traditional effort-affecting variables, they are not the only ones. As a unique team in a specific domain, there could be other
factors that influence how you size a PBI.
For example, you could include the team’s skills and experience with the work involved in the PBI. If your company is new to scrum and your team isn’t yet fully cross-
functional, you could include external dependencies or the need to fill in a skillset missing on the team. Whatever the variables, make sure they have meaning for your
team’s estimation of effort.
By estimating the product backlog items together, the scrum team can see if certain items will involve excessive effort, in which case they may decide to break that
one item down into smaller items to be tackled separately, or they may need to take on less work to accommodate the large item.
If they use an estimation metric like story points consistently over time, they can see if they’ll be working on a greater, lesser, or roughly the same number of points as
they’ve worked on in previous sprints.
While many a scrum team has experienced success with story points and user stories, they are not included as a rule or guideline in the scrum framework. That
doesn’t mean you shouldn’t use them. It means they are resources that can be added to your implementation of scrum.
Scrum is a lightweight framework with the core components of team accountabilities (formerly called “roles”), events, and artifacts (the product backlog, sprint
backlog (/Article/sprint-backlog), and increments). Anything outside of these core components (and a few related rules) is technically outside of the scrum
framework.
Not sure if you need story points? Whether you’re a developer, product owner (https://www.scrumalliance.org/get-certified/product-owner-track/certified-scrum-
product-owner), or scrum master (https://www.scrumalliance.org/what-is-a-scrum-master), you can propose this idea to your scrum team for feedback. Try using
story point estimation if you aren’t already, then include the process as a topic for a sprint retrospective (/Article/sprint-retrospective).
Your team’s feedback and findings in the retrospective can help the developers decide if they want to continue the use of point estimation, modify it, or leave it behind.
It is ultimately a developer’s tool for understanding their work and capacity, so they are the scrum team accountability who gets to decide.
It’s the relativity that allows developers to compare the scope of one item to other items.
There are many different estimation techniques commonly used by agile teams. We'll discuss a few of them here as options.
There’s plenty of room to experiment. Consider trying a few different sizing methods to see which one the developers on the team agree is best.
Less important than the actual representation of the measurement is the relative size between the items. A product backlog item assigned a two is twice the effort of a
PBI assigned a one. An alligator compared to a kitten may seem completely silly, but the team will gain a shared understanding of the relative difference between the
two as they use this sizing metric over time.
Fibonacci Sequence
It’s not uncommon to see scrum teams using a Fibonacci sequence to estimate PBIs. Here’s what the scale looks like:
When assigning a story point, a group of three developers could easily come up with a three, four, and five for a specific PBI. The numbers are quite close and less
obviously distinct. On the other hand, the difference between a two, five, and an eight is more recognizable. It’s often easier to discuss the reason for the difference in
points when they’re farther apart. Discussing the difference between a three, four, and five can feel like a waste of time because the numbers are so similar.
You can achieve the same thing with a sequence that doubles numbers: 1, 2, 4, 8, 16, 32.
Insights from this conversation can be incredibly valuable. Especially when the size estimates differ widely. For example, when one developer sizes a PBI at eight and
another assigns a three, a conversation ensues about why each developer chose the size.
The ultimate outcome may be that the full scope of the work wasn’t understood by everyone. Perhaps there is some risk or complexity that only one developer
recognized. Now they can align on the scope.
On the other hand, the developer who assigned a three may have recognized an opportunity. Perhaps a new tool or pivot in processes can eliminate a wasteful part of
the work. The developer can explain this opportunity to the rest of the developers so they can understand it and align on the size of three.
The reason? Agile teams emphasize their interaction and collaboration over processes and tools. Don’t let this tool hamper your ability to collaborate and deliver
value.
There are a few common ways scrum teams engage in a light process to estimate PBIs:
Planning poker. Someone reads the PBI and the developers use cards with the points written on them to vote on the size of the PBI. You can hold up a card for
all to see or use an anonymous version. Discrepancies are then discussed and resolved, which not only leads to a point assignment but also creates an
opportunity for the team to discuss the work and get a better idea of the scope.
Have a discussion. The developers can simply take a few moments to discuss the PBI and agree on a point or size. Some teams don’t need anything more than a
brief conversation.
Vote, then discuss discrepancies. Take a quick vote on the size of the PBI and then hold a brief discussion to resolve any major discrepancies.
Try different estimation techniques for a few sprints each and then evaluate those methods as a team. This way, you will find the technique that best suits your team.
Story Points Are Not Meant to Pressure a Team to Beat Their Record
Management may be tempted to view story point completion as a performance metric. After all, it’s easy enough to look at a team’s completed story points for a sprint
and see if it’s far lower or higher than previous sprints or other teams.
Ever higher story point completion during a sprint is not the purpose of estimation. That tends to lead to employee burnout and developers inflating their estimates to
prove progress.
Story points completed from sprint to sprint can be a useful metric for the scrum team (/Article/scrum-team) internally over time. Deviation from the team’s historical
or expected velocity may indicate something meaningful. For example, are there certain parts of the team’s processes that have caused them to complete fewer story
points than they expected? Were there certain changes the team made that caused them to complete far more story points than planned? Is a high number of points
coinciding with one or more employee vacations or absences? Velocity can inform these conversations.
(https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fresources.scrumalliance.org%2FArticle%2Fstory-point-
estimation&title=What+Is+Story+Point+Estimation%3F&summary=Story+point+estimation+is+the+process+of+assigning+story+points+to+a+product+backlog+item
(https://twitter.com/intent/tweet?text=https%3A%2F%2Fresources.scrumalliance.org%2FArticle%2Fstory-point-estimation)
(https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fresources.scrumalliance.org%2FArticle%2Fstory-point-estimation)
RL_468_story-point-estimation
Stay Connected
Get the latest resources from Scrum Alliance delivered straight to your inbox
Subscribe (https://www.scrumalliance.org/subscribe)
(htt // lli )
C E R T I F I C AT I O N
(https://www.scrumalliance.org/get-certified)
COACHING
(https://www.scrumalliance.org/agile-coaching)
COMMUNITY
(https://www.scrumalliance.org/community)
User groups (https://www.scrumalliance.org/resources/groups)
(htt // lli )
Global Scrum Gathering Amsterdam 2023 (https://www.gsgams23.com?promo=GSGAms23SANav&tr=true)
RESOURCES
(https://resources.scrumalliance.org)
ABOUT
(https://www.scrumalliance.org/about-us)
About us (https://www.scrumalliance.org/about-us)
Bylaws (https://www.scrumalliance.org/About-Us/Tax-Forms-and-By-Laws)
Privacy (https://www.scrumalliance.org/privacy-policy)
Terms (https://www.scrumalliance.org/legal)
On a mission to advance real-world agility by equipping and inspiring the changemaker in everyone.
(https://www.facebook.com/scrumalliance/)(https://www.linkedin.com/company/scrum-(https://twitter.com/ScrumAlliance)
alliance/)