At work, we use the Scrum methodology to organise our work. Without a certified scrummaster to whom we can refer, we end up making it up and adapting as we go.
I keep getting questions about “story points” and I feel like I’m not answering them correctly nor adequately. Here are some professional scrummasters taking on this topic:
A coworker suggested that it’s a way to indicating how big of a margin of error there is on an item, i.e. the more complex something is, the more likely our time estimate’s going to be off. That’s a very good insight to tie it into the time, but I think there’s definitely more to it than that. For one, you can’t fill a sprint completely with highly complex item, even if they fall well within the timebox; your team will likely get frustrated and burn out. I think it says more about how hard something is, how much unknowns are involved, and other hazy, hand-wavy gut-feel things that are not easy to measure.
The reason why they are not easy to measure is because your team is made of humans who vary from one another from one day to the next. Refactoring five major classes might be easy for one guy, while another has an easier time upgrading to a new framework. Last Friday I was having a terrible time condensing my research and thoughts into words; today I can’t stop writing.
A hazy metric like story points is a pretty fit for measuring complexity, especially for items that don’t require immediate inspection. It strikes me as something that is really only useful for the Product Owner, so it only needs to be as good as the PO needs it, which isn’t really fine-grained. (I think I’m in most agreement with Mike Cohn’s view on using story points.)