How to size agile user stories

Estimating story sizes suck. Do your teams use guesswork to estimate story sizes? Are estimates always way off? Is your sprint velocity erratic? Do your sprints never get completed? Do you struggle to get engagement from your team during estimation? All of these are not uncommon problems. You’re not alone.

Over ten years, I’ve improved many of these issues using the following strategy. Ask the team which they prefer;

1) Estimating user stories

-or-

2) Resizing user stories (not estimating, resizing)

Estimating user stories

If you will estimate the size of your well-groomed user stories, take it seriously. Get better at doing estimates. Emphasise getting more accurate over time. Use a consistent method to do estimates. Three things will help you get better estimates if you keep the method consistent.

1. A golden reference story that is 3 points. This stays with the team forever. Or until you find another golden reference story that is 3 points,
2. A reference story from the last sprint that was sized right, but not 3 points.
3. A matrix where the point size of a story is the intersection of complexity and effort relative to story one and story two. Use the matrix below;

The axes on that matrix prompt thought and conversation when comparing one story to one already sized right. Try it out yourself, and you’ll understand what I mean.

Sizing user stories

This isn't estimating the size of a story. No estimating is involved. The activity is resizing the stories. Put effort into grooming and organising stories so all stories are small enough.

Let's say they are all "3 arbitrary points". Then we don't need to do estimates again - it's always 3-ish points, and that's fine as long as the right amount of care and thought has been applied to breaking down stories into small, consistent sizes pieces.

You will know if you're sizing stories right based on standard metrics such as velocity.

I hope these ideas help you form your thoughts on how to make estimating story sizes suck less.