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
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.
Further reading on why you might be wasting your time with story point estimation.
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