Agile & Story Points: Things You Must Remember
If you are a software engineer or project manager aiming to efficiently and reliably ship software using an agile approach, it's good to remember:
-
Story point estimates are meant to be an estimate of difficulty/complexity/risk, not time.
-
Even though they're not meant to be time estimates, that's how almost all engineers determine estimates in their heads. This is because story pointing often goes hand in hand with committing to stories for an upcoming sprint with project management.
-
Whether they admit it or not, time is also how most project managers think about estimates. This is because they need to communicate -- to customers and others in the company -- when they can expect certain features and fixes.
-
Every engineer's pointing system is different and individual. Sure, everyone may be using the Fibonacci sequence, but 5 points for Engineer A is different than 5 points for Engineer B. Yet, for time estimation purposes, both engineers & project managers will try to reason in their heads about "what constitutes a 1/2/3/5/8/13 point story.” It is also common for junior team members to adapt their estimation system based on how they see more senior engineers point stories, which adds another layer of abstraction to “what points really mean.”
-
Not only are point estimates individual, but they're also only meaningful over long periods of time. One thing good project managers aim to do is predict software delivery time using measures of developer and team velocity. This assumes that individually all developers more or less float around the same output sprint-to-sprint, which may be true for some but definitely not for all. For team velocity, it assumes the team stays the same without any additions or subtractions, which on most modern-day tech teams is rare.
Story points can be useful, but it’s important to see them for what they are: abstract estimates that mean something different to everyone on the team. When you treat point values as if they are inherently meaningful or the source of truth for predicting delivery timelines, you open your team up to confusion, frustration, and failure to deliver. Long-term, this affects morale and your ability to retain and attract top talent.
What are your experiences with agile and storypointing? If you’ve worked on an agile team building modern software products, I would love to hear your thoughts and experiences on the topic!
