Story Points? How to do Agile Story Point Estimation

If you’re going to use story points in Scrum, here’s how to do it. Story point estimation can drag Scrum teams and software developers into a pit of despair, frustration, and waste. There’s a lot of confusion surrounding the use of story points in Agile teams. The estimation technique described in this article enables you to accurately size stories in a fraction of the time you would normally take. Make sure you read to the end of this post to find out why estimating using story points is a complete waste of time and you really need stop doing it!

Common flawed approaches to story point estimation

The majority of popular story point estimation techniques use an absolute approach to estimating story size. When we do absolute estimation, we attempt to quantify the amount of time it takes to complete a task, or to represent the effort required as a point estimate. Team estimates often use planning poker to facilitate a conversation about absolute size using the Fibonacci sequence. Is this story a 3 point story or a 5 point story? If one team member assigns story points of 3 and another person estimates an 8 then sure, a great conversation emerges but it is still absolute estimation.

The true purpose of story point estimation

The first rule of sizing user stories is, never ever (directly or indirectly) size stories in any unit of time. The second rule is to always use relative sizing and avoid at all costs absolute sizing.

The objective of sizing stories is to get everything about the same size. If all work items are (relatively) about the same size, it reduces variation in your throughput. If we can reduce one of the sources of variation with a reduced batch size, then we increase flow and increase predictability.

How to size stories quickly and accurately - t shirt sizing in Agile

User Story T-Shirt Sizing

Team members, including the Product Owners attend the sprint planning for story sizing. Take one or more product backlog items and break them down as necessary. You’ll need your stories written out (or printed) onto index cards – this is a great job for the Scrum Master! As story point estimation is usually conducted in sprint planning, you should have plenty of stories to work with. This is due to the batch nature of Scrum.

Create four virtual buckets with the headings Small, Medium, Large and Extra Large. Find the biggest base story first, place it in the Extra-Large bucket. Find the smallest base story, place it in the Small bucket. Now distribute all other stories between these markers. Look to break down extra-large and large stories further. You know you’re done when you can no longer break stories down or distinguish the difference in sizes.

You will now have stories in each column. You’re looking for a distribution of stories where the majority of your stories are medium or small. If you only have small and medium stories, then great.

At this point, if you really really want to use story points then make the translation to story points. Use an exponential scale rather than Fibonacci scale:

  • Small = 1 point
  • Medium = 2 points
  • Large = 4 points
  • Extra-Large = 8 points

Starting with t-shirt sizing and then translating to story points is important from a psychological perspective. By using non-numeric t-shirt sizes, we reduce the risk of associating units of time with size. Once we’ve sized we can then safely translate into numerical based story points.

This technique is commonly known as t-shirt sizing. Pay attention to the detail of how this technique is implemented. First, we use relative sizing not absolute. We do this by finding the biggest work item and the smallest. Everything else is offset in between. Second, we only make the translation to story points once we’ve completed relative t-shirt sizing. Third, we’re sizing, NOT estimating! If we break everything down where possible so everything is about the same size then why the need to use Story Points at all? Please stop using story points.

If you and your team use story point estimation then you might want to think about dropping story points altogether.

Agile Estimation, Planning and Forecasting

Take a deep dive into Story Points, Agile Estimation, Planning and Forecasting on our 2 day instructor led online course. Organisations often struggle to accurately estimate work, resulting in damaged stakeholder expectations, late delivery and demotivated staff. In this series of workshops you will learn how to accurately estimate Agile user stories, Features, Epics, projects and even entire programmes of work using the latest techniques from industry experts.

Story points estimation and why you might be wasting your time

Story size is a relative sizing method commonly calculated using planning poker. The fibonacci scale is one approach but there are others including 1,2,4,8,16, and S, M, L, XL.

story points

Measuring Cycle Time

Cycle time is the measure of how long a story takes to move from the point at which work starts on it, to the point considered to be done.

basic card wall with cycle time label

The problem with story points

When teams use planning poker I’ve observed in pretty much every case that they infer a correlation between relative size and how long a story should take to complete. For example, it wouldn’t be unreasonable to assume that a story estimated at 13 points will take longer to complete than a story of 1 points. In other cases I’ve observed an assumption that defects are generally smaller than stories. Viewed in a chart these preconceptions might look something like this:

hpw we image story points look

As you can see, the amount of time it takes for the work to be done is neatly aligned to the relative size estimates.

However, back in the real world the picture is somewhat different. The reality is, there is often little correlation between story size and the amount of time it takes to do the work.

What does the data tell us about story points?

We collected data from 25 teams across 4 different organisations. Each dataset contained on average 500 data points from a mixture of stories and defects. In total, the data contained estimated size and total time taken for over 12500 work items.

The chart below shows the data for one of the teams. This chart is interesting as it shows the larger the sizing the less predictable the time taken to complete is – apart from the three 8 point stories which should of been sized as 1 point stories??

what story points really look like

I then pondered over the idea that maybe some teams are only considering the dev effort when sizing so I narrowed the definition of done down to just measure the cycle time from Ready for Dev to Dev Done/Ready for Test. Now clearly, considering your code to be done if it hasn’t been tested, UAT’d, and deployed to Live is pretty insane and I’m certainly not recommending it. What I’m interested in here though is the accuracy of story sizing when just considering dev effort. The following chart plots just the cycle time for stories from Ready for Dev to Dev Done.

dev only sizing vs cycle time

Again, low correlation. Here’s data from two more teams measuring cycle time from Ready for Dev to Ready for Live:

Team 1

So if sizing of stories can’t give us any indication of how long it will take to deliver work then what’s the point of story sizing? Let’s now look at why story size doesn’t always correlate with cycle time.

Agile Estimation, Planning and Forecasting

Take a deep dive into Story Points, Agile Estimation, Planning and Forecasting on our 2 day instructor led online course. Organisations often struggle to accurately estimate work, resulting in damaged stakeholder expectations, late delivery and demotivated staff. In this series of workshops you will learn how to accurately estimate Agile user stories, Features, Epics, projects and even entire programmes of work using the latest techniques from industry experts.

Variation

To understand why estimated size rarely aligns with time taken you need to explore what causes of variation you have within your delivery process. Variation comes in many forms and each company and team will present their own nuances. Here’s just a few sources of variation common to most delivery teams:

  • Lack of visibility of work.
  • Waiting for people to become available.
  • Availability of people in different time-zones (for distributed development teams).
  • Story size variation.
  • Story complexity variation.
  • The time it takes to resolve questions when relying upon other team members.
  • Context switching due to having too much work in progress.
  • Unrealistic timelines.
  • Poor prioritisation of work.
  • Hand-offs to other teams or 3rd parties.
  • Lack of automated test coverage resulting in regression and extended manual testing time.
  • Incorrect sequencing of work resulting in local dependencies.
  • Staff churn / turnover.
  • Variation in capabilities of individuals.
  • Misinterpretation of requirements.
  • Effect of productivity variance.
  • Waiting time when people are diverted to deal with incidents or other work.
  • Technical environment issues.
  • Poorly written user stories.
  • Sharing staff across multiple projects.
  • Release contention across multiple teams.
  • Environment contention – availability of technical environments at the right time.
  • Processes external to the team introducing waiting time.
  • Waiting for sign-off from departments external to the team.
  • Waiting for assets to be delivered from other teams, e.g. UI assets.
  • Build up of technical debt.
  • High defect rates resulting in rework.

There are many tools in the Agile / Kanban toolbox that can help us to reduce variation (you can’t eliminate variation). If you can reduce variation you become more predictable. If you become more predictable it makes planning easier. If you make planning easier you can manage expectations more effectively.

How to plan and forecast in an uncertain world, with or without Story Points?

Work item size is variable but adding in the biggest form of variability – waiting time, how can we possibly plan or manage expectations? There are at least two, really simple techniques for planning, forecasting and clearly managing stakeholder expectations.

  1. Burn-up chart
  2. Throughput distribution chart

Both techniques can incorporate monte-carlo simulation and both are based on historical data.

The Burn-Up Chart

A burn-up chart is a planning and tracking tool used by Agile teams to communicate progress against a specific goal. The reason they are so powerful is they are empirically based and remove the need for teams to estimate. This greatly simplifies the whole planning process for everybody.

Why use a burn-up chart?

  • Simplified planning and tracking
  • Easy to create, interpret, and maintain
  • Low effort / low maintenance
  • Low tech – no complex software required to create. You can even create with a whiteboard and pen!
  • Removes burdensome estimation activities from teams
  • It’s empirical based so more accurate than estimation based planning
  • No need for teams to update effort remaining for each task at the end of each day
  • No need to track % complete for each work item 

Who creates the burn-up chart?
Typically, the Scrum Master, Project Manager, Delivery Manager or Iteration Manager is responsible for collecting the required data, creating the chart, and publishing the chart for the team and key stakeholders. A better approach would be to completely automate the creation of the chart.

Burn-Up Chart with monte-carlo simulation

The burn-up chart above shows total scope (card count or story points) over time (orange line) and actual amount of scope delivered (green line). Using a monte-carlo simulation of 10,000 runs we can work out the 25th & 75th percentiles of probability. This provides a landing zone of where we might complete the current scope. 

Steps to Create:

  1. Create a spreadsheet as per example below
  2. Each Friday, count how many cards the team has completed and enter this figure in column C
  3. If the scope changes, update the value in column B and extend the values in the same column for the remaining time ahead of the row that changed
  4. Add trend lines to the graph if required or draw your own trend line representing best case / worst case landing zones based upon amount of variation in delivery to date.

Throughput Histogram

Agile Estimation, Planning and Forecasting

Take a deep dive into Story Points, Agile Estimation, Planning and Forecasting on our 2 day instructor led online course. Organisations often struggle to accurately estimate work, resulting in damaged stakeholder expectations, late delivery and demotivated staff. In this series of workshops you will learn how to accurately estimate Agile user stories, Features, Epics, projects and even entire programmes of work using the latest techniques from industry experts.

About Ian Carroll

Ian is a consultant, coach, trainer and speaker on all topics related to Lean, Kanban and Agile software development.

Connect with Ian at the following

FREE KANBAN CHEAT SHEET

Leave a Comment

Your email address will not be published. Required fields are marked *

Further information...

The content of this article is just the tip of the iceburg. To dive deeper into any of these case studies or concepts join our 2 day Portfolio Kanban live online course.

Application for a free Agile Coaching session

I would like to speak with an advisor

2 Shares
Tweet
Share
Pin
Share
Email