Why use story points? Because everyone sucks at estimating!
Many teams that are just getting started think about using story points as a replacement for putting hours on tasks in their old project plans. If you equate story points to hours or do that translation in your head, you’re doing it wrong. And I’ll explain why. There are some very subtle but very important reasons why teams use story points in an agile process.
Relative Estimation
So the first reason, as the title of this post says so boldly, is because you might just suck at estimating. And I say that only half joking. The point is you should be able to suck at estimating, so that you don’t spend much time on it. But also because if your stories are small enough, the variance isn’t so much that it will kill you. If you’re off by 50% on 2 days worth of work, it’s not a huge deal. But if your stories are measured in weeks, then yeah you’re going to have some big surprises and that’s not good for the team or anyone.
As an agile coach, I like to tell teams that their longterm goal should be to vertically slice stories to approximately the same size if possible, because then you don’t need to estimate at all. You can just count cards. For some entertaining twitter threads, look up #noestimates. The strong opinion there is that any time spent estimating is wasteful because you’re not doing the real work that matters: delivering value.
If you are doing it wrong :) consider resetting the way you estimate. Here’s how to start over: Pick an anchor story to reset your definition of medium. Something everyone understands and something that clearly delivers value through every layer of work you need to do as a team. Pick one that is definitely medium in size, no more than roughly 2–3 days worth of work. Call that a 5 if you’re using Fibonacci (or 500, it doesn’t matter). Then every time you estimate anything, compare it to this anchor story. Is it bigger or smaller? Twice as big? Twice as small? This will ensure that if in fact you do suck at estimating, you will at least suck consistently! Which, frankly, is the whole point.
Shared Understanding
You’ve probably learned about the “Three C’s” when you were taught about user stories. The Conversation is the key when it comes to estimating. Whether you do a planning poker thing or a three amigo thing, make sure you have a conversation with the team about every story before it’s deemed ready and be sure to discuss any differences of opinion. The goal isn’t to ignore differences and get through it quickly, but to gain a shared understanding through reviewing the differences of opinion so as a team you’re not missing anything. Think of this as your technical design phase. The conversation with the team is in the spirit of “how do we think we’re going to achieve this outcome”. And if someone thinks it’s hard, the team should want to know why in case you’re forgetting something or there’s an unknown to be worked out or maybe that API call doesn’t do what you think it does, etc.
Sustainable Pace
When you add up all the story points of the cards you complete in a sprint to come up with your velocity number, don’t worry too much about what that number means. It’s just a number. That word velocity gets people thinking it’s supposed to be an indicator of speed. But that’s a horrible and unfortunate thing. Instead, the team should think of their velocity as a reasonable capacity and the reason they can achieve a sustainable pace. (See more here: Velocity’s Killing Your Transformation)
A team’s velocity is meant to fluctuate. Think of it as being “Usefully wrong and directionally correct”. The beauty of this estimating technique is that no one needs to audit the hours spent in meetings, the half-day town hall, who had doctor’s appointments, who did laundry from home this week, and who had beers starting at 3:30 on a Tuesday. The velocity takes all of this into account by simply measuring what got done. And if you average your last few sprints (maybe even the last 5 or 6 sprints) then you’ll have a very representative number, based on your consistently estimated work, of just how much your team is able to do. And if you’ve limited your work to 40 hours, and use prior velocities to come up with a reasonable guess about what your team might be able to do in the next sprint, then you are ensuring your ability to maintain a sustainable pace.
What if one of your 5 team members is going on vacation for half of the next sprint? No problem. Simple math. Just reduce your velocity by 10%. It’s all relative.
Build Trust in Delivering Value Incrementally
If you combine this relative estimating technique with a rigorous product backlog prioritization process (that is aligned with the strategy of your company, maximizing value for your customers based on tight feedback loops and an empirical process…) something incredible happens. You can say the following statement:
Our team guarantees that we are working on the absolute most important outcomes for our customers at all times and will deliver incremental and demonstrable value every two weeks!
For middle managers and stakeholders that have only started learning agile, this can be a shocking statement. They may not even believe you at first. But… if you hold Sprint Reviews every two weeks and invite them and demonstrate the value you’re delivering and tell them what you’re doing next, they will start to see. And then you do it again two weeks later and show the value you’re creating, explain why it was important and share what you’ve learned and the adjustments you’ve made through the conversations and feedback you’ve collected… Then you will have built the foundation for trust and accountability that will help eliminate some of the old school questions about longterm milestones, working weekends, artificial fire drills, etc.
I hope this helps you think about story points differently. They’re not the most impressive thing in agile and they even get quite a bit of backlash (mostly because I think a lot of people misuse them!) But if you can do the few simple things I’ve mentioned above, I really do think they can help you and your team reinforce some very key agile concepts and improve your ability to focus and deliver.
If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
