Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Demystifying Story Points

Deadlines
Agile / Scrum

30 September, 2020

Nael El Shawwa
Nael El Shawwa

Head of Engineering at Perpetua

Nael El Shawwa, former VP of Engineering of Shutterstock, dissects the mystery behind assigning story points to tickets emphasizing that estimates should always be relative.

Problem

Story points are downright difficult and from the outside it appears like strange magic. Everybody does them differently. Non-technical managers don’t understand them. They can be mistakenly correlated with productivity (i.e. more points per sprint is better) or with time (i.e. more points is more time). Most engineers are keen on the process, but many will approach it by correlating it with a time estimate. For example, this will take me 3 days, so it must be a 3 point story. Story points become meaningful only when you break down the correlation with time and use them to compare complexity between different types of work. Without this necessary change, you are likely to miss your sprint goals frequently for it to be a big problem.

Actions taken

To fix this problem we have to reframe our and the teams’ understanding of story points. We have to look at them as a measurement of complexity and never time. Rather than time, we need to assess each story from the perspective of a) complexity b) risk and c) unknowns. Complexity is often how we estimate our work. Naturally more complex work will take more time. We often don’t think a lot about risk and unknowns until much later and that’s usually when we realize our estimate was off. Risk is a measurement of how risky the change we are proposing is. Is it localized to specific areas? or could it cause wide-spread challenges that we have to resolve? Finally, unknowns is a confidence measure of how well you are familiar with the complexity of this solution and the risk it presents.

Often when we are grooming a story we will arrive at a situation where various individuals may have conflicting assessments of the complexity, risk and unknowns. How we deal with this situation is crucial for success. Never split the difference, never average, never default to the most senior member in the discussion. The only way to resolve this is through discussion to understand why various members think something is more complex, or more risky, or we have more knowledge gaps that we realize. After this, we must re-do the breakdown given the new information we learned. In another Plato story I discuss how to re-frame estimates as budgets.The technique around trade-offs shared there comes in very handy in this situation as well.

This approach will not only help you to come up with more precise estimates but will help you dissolve the perception that the team is not productive. A good estimation process is all about demystifying how we assign story points through a repeatable process.

Lessons learned

  • Estimates should be relative. Two estimates should always be relative to each other. They are not time estimates that are based on absolute numbers. From a sprint perspective, it will help you to understand how many different types of complex pieces of work you have.
  • When the team is discussing story points and disagree, they have to spend more time to understand why they are disagreeing. This only occurs if we have different information, otherwise given identical info we should be aligned on our story points.
  • Optimism bias is inherent in each of us. Our wishful thinking always leads us to override the voice of experience. This fault is the cause why time-correlated story points will lead us astray in our estimates.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Working From the Ground Up

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, uprooted an entire product and built it back up again with the help of his team.

Deadlines
Toxic Atmospheres
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Build a Software Team from the Ground Up

12 November

Deepesh Makkar, Sr Director of Engineering at SunPower Corporation, shares his experience transitioning his organization from contractors to a 50/50 split of full-time employees and international vendors.

Hiring
Motivation
Cross-Functional Collaboration
Agile / Scrum
Deepesh Makkar

Deepesh Makkar

Sr Director of Engineering at SunPower Corporation

Succeeding as the First Product Hire in a Startup

2 November

Priyanka Naik, AVP of Product and Technology at J.P. Morgan, shares her plan to bring a product to execution as the first product hire in a startup.

Alignment
Goal Setting
Product
Deadlines
Roadmap
Priyanka Naik

Priyanka Naik

AVP - Product and Technology at JP Morgan

Choosing the Perfect Implementation of Agile

25 October

Shubhro Roy, Engineering Manager at Box, stresses the importance of the holistic nature of Agile methodology; picking and choosing à la carte may cause more problems than it solves.

Goal Setting
New Manager
Agile / Scrum
Shubhro Roy

Shubhro Roy

Engineering Manager at box

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.