How can I turn story points into time?
You don’t.
But what if I did?
You don’t.
Listen, I made a table to convert them?
Well,you can’t.
But table?
No.
And then everyone clapped and started using story points correctly.

As seen in the absolutely real conversation, management loves to turn story points into something they are not.

Story points are used in scrum to estimate the complexity of user stories. User stories are individual stories that describe features through the eyes of the user through individual stories. Before each sprint, the team sits together and estimates how complex an individual story is by assigning points to it.

A complex story has more points than a less complex one. Ideally, a story that has five times the complexity than another story has five times the points.

Management may ask the team to work harder and deliver more story points, Or management may compare teams by the number of story points produced.

Management may use story points for time estimation. “Well, last time Peter made five story points per week, so that means a story point equals one day.”

Management may assume that one five-point story takes the same time as five one-point stories.

Or the team has decided one story point equals one day for one person. That wasn’t so hard, was it?

All of these are wrong. Not 90% wrong or a little wrong — they are fundamentally wrong.

They are also probably using story points wrong. Photo by İrfan Simsar on Unsplash

Management is hard. Estimation is hard. I get it. I understand the temptation to use story points in that way. I really do. I’m not great at estimation either, because it really is tough. So why not use story points? The team has already spent time arguing about them.

They are a number. They are related to the team's output. Numbers are used for estimation. Managers do estimation. Ergo, use story points for estimation.

Because they are not for the management. They are for the team. They are in the control of the team. Their only function is that the team is not taking on more complexity per sprint than it can handle.

Something that can be used to estimate time. Photo by STIL on Unsplash

OK sure, I hear you say. But a sprint is a unit of time. Estimation uses time. So divide the generated story points by the time of the sprint. Estimation!

Story points are a tool for the team. They have no meaning outside the team. If they get a meaning outside the team, they become political.

Then the team gets questioned about why they were able to deliver fewer story points than before. But story points are arbitrary numbers that measure complexity for the team. You can just add ten points to the estimated value and suddenly you are a lot more productive.

The role of story points is to measure complexity. How much complexity can the team handle per sprint? That is simply not the same thing as time.

The human brain can only handle so many hard tasks per day. A developer is not a machine that turns time into features. “If eight hours mean one feature, then 16 hours mean two features per day” is obviously not true.

People get tired, there is only so much energy to focus in a day. After one or two hours of focusing, everyone needs a break. Software solutions often require creativity. A creative bash script can sometimes do what 300 lines of Java can’t. But creativity is not simply a function of time.

There is an amount of complexity a person can handle, irrespective of time. If you study a language for four hours a day, you will not understand in half the time if you study eight hours a day.

That’s probably more than one story point right there. Photo by bruce mars on Unsplash

What you’re going to end up doing is spending four hours at most learning and then a lot of time getting a coffee, reading Reddit, or watching YouTube, because a human’s capability to focus is limited.

So if a story has five points, it does absolutely not mean it takes five times as much time as a one-point story. It means it’s five times as complex as a one-point story.

It’s very possible that five one-point stories take more time than one five-point story. Stories need time to switch context: see, where you left off the last time, maybe get the latest code, update the status, and so on. But a five-point story is as complex as five one-point stories, so it may involve quite a bit of focus and concentration.

On the other hand, a one-point story may be easier to squeeze in at the end of the day, when the big stuff is done.

Another thing that can be used to estimate time. Photo by Sonja Langford on Unsplash

When estimating story points, it is also not clear who will do the task. Maybe some team members are more experienced than others and can finish it faster.

Maybe some are busy with other things, and it will take them longer to finish. None of these facts affect the complexity of the story. The complexity remains the same, independent of who does it and independent of how much time in a day they spend on it.

If you need to measure and report time, you can just report the features that will be delivered at the end of the sprint, or simply estimate. Use good old management techniques and estimate the time it takes. Put it in a spreadsheet or project-planning tool. But don’t use the story points for that.

Or don’t use story points. Drop the whole “planning poker” charade. The scrum process is not a must. There are other processes.

Software was developed before scrum and will probably be developed after scrum. But please don’t do pretend scrum and use story points for something they are not designed for.

The function of story points is to make sure that the team can handle the amount of complexity in the current sprint. That’s it.