Agile Story Points

User stories are one of the core concepts in agile software development. You need to build and maintain a prioritized backlog of estimated stories. Stories are accepted into an iteration from the top of the backlog during iteration planning, and the assigned resource becomes responsible and is held accountable to complete the story within the iteration.

One of the challenges with this process is estimating stories to ensure that they are scoped correctly to safely fit into and be completed within a single iteration. This is where story points enter the equation.

Story points are intended to provide a relative scale of effort for stories, but the unit of a story point is very open to interpretation and seems to vary throughout the community. To me, the most obvious unit for story points is hours. Others have suggested that you use a single, perfect day as the basis, or use a half-day. The problem I have with these suggestions is that there is an implicit conversion that occurs. And what about a story that will only take an hour or two? Days-as-points is too coarse.

Another suggestion I’ve heard is to use the simplest story you can think of as your points baseline. I like this idea. The problem is that I’d estimate the simplest story I can think of to take one hour, and then I’m right back to hours. Alternative units don’t seem to be alternative at all. Instead, I’m just doing extra math to abstract the numbers into something other than hours. At the end of the day, though, everything is still hours-based.

That’s how I felt about story points for a long time. I recently started thinking about story points in a slightly different way, and it’s working for me. Instead of converting to a different unit, I’ve been thinking about story points as an hours-based estimate that is equal parts effort, uncertainty, and complexity.

There are stories that I know will ultimately be fixed by a line or two of code, but they need some figuring-it-out time. The final effort required to complete the story is minimal since it’s probably just going to be a couple of lines. Assigning story points based on minimal effort that’s been adjusted to account for risk due to uncertainty and complexity works great. The story points estimate for this story will be comparable to a high-effort-but-simple, brute-force-type of story.

At the end of the day, the story points scale you and your team uses doesn’t matter as long as it works for you. You want your stories to have a story points estimate that indicates their total required effort, taking into account risk due to uncertainty and complexity. The team should feel good about accepting a story into the iteration and getting it done. You should be able to use the story point estimates from completed stories to determine your team’s velocity and predict future results.

Have you been down a similar path of enlightenment? What have you found that works or doesn’t work?

Author: Adam Prescott

I'm enthusiastic and passionate about creating intuitive, great-looking software. I strive to find the simplest solutions to complex problems, and I embrace agile principles and test-driven development.

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: