We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Demystifying Story Points

Agile / Scrum
Deadlines

30 September, 2020

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.

Related stories

The Quick Fix to a Slow Team: A Consultant’s Perspective
30 September

Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.

Team processes
Delegate
Productivity
Agile / Scrum
Peter Berg

Peter Berg

Founder / CTO at Forward

The Hidden Value of Agile Processes
30 September

Brian Guthrie, VP of Engineering at Meetup, shares how he learned the hard way that many Agile processes he eliminated had their second-order effects that the team was benefiting from greatly.

Agile / Scrum
Brian Guthrie

Brian Guthrie

VP of Engineering at Meetup

Demystifying Story Points
30 September

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.

Agile / Scrum
Deadlines
Nael El Shawwa

Nael El Shawwa

Former VP of Engineering at Shutterstock

Reframing Estimates
30 September

Nael El Shawwa, former VP of Engineering at Shutterstock, explains why reframing estimates is necessary and how that resonates with the very nature of the engineering work.

Deadlines
Agile / Scrum
Nael El Shawwa

Nael El Shawwa

Former VP of Engineering at Shutterstock

Don’t Let Yourself Be Held Hostage by Estimates
14 September

Marian Kamenistak, VP of Engineering at Mews, discusses how constant delays are usually caused by things other than inaccurate estimates.

Deadlines
Prioritization
Marian Kamenistak

Marian Kamenistak

VP of Engineering at Mews

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.