Formal Agile and Scrum training uses things like Story Points or T-Shirt Sizes for user story estimation. Although I have done lots of reading and training, I still have a hard time understanding how this would work in real life, given that it is very intentionally stated in the formal academic training that the Points or Sizes should not have any correlation to calendar/wallclock time. I ended up having a lengthy conversation with a friend (Ken Stearmer) who is a very experienced Scrum Master. The way he explained it was as such:

You assign the Story Points to the Stories and then run the Sprints. Eventually, given enough time and data collection, you can start to get an idea of how many Story Points the team can accomplish in a Sprint (i.e. the team’s “Velocity”). That lets you know how to “fill up a Sprint” with User Stories.

So this makes sense to me academically, but I have what I call my “pragmatic overlay”, which is, how would you do this in real life. Some ideas sound great on paper, but in real life, with real people and real risks and real customers and real dependencies, the ideas don’t always work as well.

One concern I have with the above approach is that for a new team you would not have any idea how to fill up a Sprint. If you don’t know the team’s velocity, then you don’t know how many User Stories to plan for a Sprint. And the reality is, your team is probably constantly changing people and perhaps even projects, so it would be difficult to ever be able to gather enough data to understand the team’s velocity.

In response to this challenge, I typically use a different approach. I still use Story Points but I correlate them to a high-level time-based effort estimation. Usually something like this:

1 point = I can get it done today
2 points = It will take a few days
3 points = It will take a week
5 points = It will take the whole Sprint (a Sprint is usually about 4-8 working days)

These Story Point estimates allow you to plan out someone’s Sprint by giving them several tasks that you can estimate will take the full amount of time of the Sprint.

I realize that this does not align with the formal Agile/Scrum methodology, and I’ve had purists call me out in public telling me that I was wrong in doing this. But after a lot of years of doing this in real life, and running teams and delivering results, I’ve learned that doing things exactly by the book doesn’t always work, that you have to be pragmatic and use your experience to tailor and adjust processes so that they make sense for your team and situation. And at the end of the day, it is not about how closely and formally you followed the processes, but whether or not you delivered value to your customers and thus your business.