Agile Story Points: Measure Effort Like a Pro

Story points in agile is a microcosm of agile development itself — working together as a team to estimate scope develops an atmosphere of collaboration, shared understanding, and continuous improvement. Agile story points can also provide clarity in a user story map by providing insights into how much effort you're planning to allocate to developing each part of your customer's journey through your product.

Story points are effort estimators. They’re an alternative to traditional estimation techniques that measure the expected effort of a project in days, weeks, or months. With agile story points, instead of asking, "How long will this project take?" we use relative estimates about the effort it might take to complete each item in the backlog. For example, an item that is assigned two story points is expected to be twice the effort as an item estimated as one point.

So, why should agile teams use story points? Let's see how story point estimation, sprint retrospectives, and velocity metrics all build consensus and allow team members a clear vision into the prioritization of your product backlog.

Story point estimation for the whole team 🙌

In sprint planning, product and engineering teams work in tandem to gain a shared understanding of the effort required to complete backlog items. During planning, the team agrees to a story point estimate for each user story in the sprint.

Point estimation is a practice in collaboration and consensus-building among team members. The team as a whole participates in determining the point value for each item in the sprint. By discussing each other's perspective on the estimates:

• Product owners better understand developers’ reasoning for their estimates.
• Developers gain empathy for the product owner's need to assess tradeoffs and make prioritization decisions from sprint to sprint.
• QA testers have an opportunity to weigh in on the complexity and risk of the work being estimated and the amount of work needed to create and run tests.

One common methodology for employing agile story points is to assign values to backlog items using the Fibonacci sequence — 1, 2, 3, 5, 8, 13, 21...you get it. Mike Cohn provides a succinct reason for this approach — numbers that are too close to each other are difficult to differentiate. This sequence of points provides a much better jumping-off point for your team to discuss the relative effort of backlog items than a liner point system (i.e., 1, 2, 3, 4, 5...you still get it).

By planning with agile story points, you avoid the temptation to place artificial deadlines on sprint items. It's also easier to reach a consensus on the relative scope of items compared to attempting to place a timeframe on each item. You'll spend less time planning and more time working on your sprint!

Estimates are...estimates

Guess what? Your estimates don't need to be perfect! The process of agile estimation is difficult but provides software development teams an opportunity to feel comfortable with story point estimates being just accurate enough to continuously develop. Over time, you will learn from each other and will improve at creating better estimates.

Unpredictability exists in every project. By using rough estimates that are relative to each other, you avoid the trap of overplanning and allow developers to get to work. Story point estimates allow teams to build smooth planning cadences and move seamlessly from one sprint to the next.

Sprint velocity and other key metrics 📈

Agile story points enable another valuable tool for teams to continuously improve their estimation process — metrics. Several metrics can be used in the context of story points and estimation, but we'll focus on two of the most popular ones — burndown and velocity.

Sprint burndown

In any sprint iteration, the team commits to the amount of work that they believe they can complete in that timeframe. A burndown chart visualizes how the team is progressing relative to its commitment over the course of the sprint.

The y-axis is the number of points in the sprint, and the x-axis displays time in the sprint. There are two lines in the chart. The ideal work remaining line connects the start date of the sprint to its end date (it crosses the x-axis to indicate all of the sprint's work is done). The actual work remaining line shows what still needs to be done. The overall idea is for this line to track the ideal line as closely as possible, meaning your estimates are sound and you are completing the sprint's work at a nice pace.

When reviewing this chart, you’ll find common problems facing agile teams. Here are some examples:

• Over- or under-committing to an amount of work
• Adding points to the sprint after it's already started
• Erratic movement in the actual work remaining line
• Overcommitments that force user stories into the next sprint

Burndown is closely related to velocity, which measures your team's pace of work.

Sprint velocity

A development team's velocity is the amount of work that is completed in each sprint. It can be used as a measure of how long it will take the team to work through its backlog. Because agile story points are as a relative estimation, teams can use them as a baseline to understand how their velocity evolves.

Here, we see a representation of a team's velocity over the course of several sprints.

Sprint retrospectives are an opportunity to discuss any issues made apparent by the sprint's burndown or the team's velocity. It's a time to reflect as a team, review your metrics, and figure out if there are opportunities to refine your process and improve together.

Here are some questions to ask during this process:

• Should we adjust our expectations of getting through the backlog?
• Do we need to tweak our estimation process?
• Should we consider adding a team member?
• Are we over- or under-committing to the amount of work in our sprints?

While these metrics provide insight into your estimation process and your team's pace of getting through your backlog, putting your items into a user story map provides another layer of context on your overall prioritization decisions.

User story mapping with agile story points

Story points are not only important in the context of sprints. Placing them in user story maps produces a visual of strategic product prioritization.

User story mapping in a nutshell 🥜

A user story map takes the items in your flat backlog and places them in the context of your user journey through your product. It's a view of all of the actions your customers take from sign-up to log-out and every major action they take in-between. Instead of having a straight list of items (backlog), the user story map organizes them by your customer's workflow.

For a more comprehensive view of this method, read our ultimate guide to user story maps.

Unflatten your Jira backlog with user story maps

With Easy Agile User Story Maps for Jira, you can see the number of agile story points assigned to each stage of your users' story map. Seeing point estimations in your customer’s journey provides product teams and stakeholders a user-focused view of prioritization.

This can help answer questions such as:

• Are we investing too much effort into one part of the journey?
• Should we smooth out the allocation of points across the journey or focus on one key problem area?
• Will the next release provide enough added value to our customers at a certain stage in their product journey?

It also provides another chance for your team to collaborate! By reviewing your story map together, you're sure to come up with more insights and iterate on your prioritization decisions.

Agile story points, combined with user story mapping, is an effective way to bring teams together to create an agreed-upon view of prioritization across a customer’s journey.