The journey from hours to story points on a real-world project

Over the past 6 months, we have moved a major client from hours to story points. I want to show you how it can be done. But first:

What are these story points and why should I move to them?

Story points are a measure of work, complexity, risk, and uncertainty all piled into one metric.

I have used story points in sprints now on and off for 7 years. Clients really never understood them. Fellow project managers never really understood them.

To a project manager, using story points is like giving your developers a code language to get out of giving estimates.

To a client, story points are even more abstract, what am I actually paying for?

As a born project manager (I was managing projects for the school when I was 9 years old), story points scare the hell out of me.

In my mind, I can’t see how they relate to actual time,
I can’t ‘buffer’ them easily to allow a margin of error,
And complexity is not something you usually deal with on a project management level (but the risk is).

However, the developer inside me likes it, as software development is innately hard to estimate.

And somethings are harder than once thought:

AND story points give you a very good idea of the nature of software development -> if you imagine 8 story points is a range of hours, rather than a specific hour, it’s easier to comprehend. It puts complexity, risk, uncertainty, and work all in one-> when hours can sometimes only capture some of these.

We were thankful to have a client in which some of the people knew the benefit of story points and actively pushed for it. On other projects in my time, the conversion wasn’t so easy. But so we are all on the same page:

Story points = Work with Risk with Uncertainty with Complexity

Why should I convert to them:

They are a better measure for story development and make developers happier in estimating, and better performing in sprint delivery in general.

You spend less time focusing on estimating, or more time on development, improving your ultimate efficiency.

Now we know what we are talking about, a short guide:

The non-complete step guide to story point conversion in your projects

Getting developers on the same page

First, you need to see if your developers know story points and organize some knowledge sharing, at least to get people on the same page.

Preparing the client for non-delivered sprints over a period of time

The first step is preparing the client for the period of time you won’t deliver a certain number of sprints -> you have to work out a sprint velocity first (a number of story points you can do in one sprint).

Preparing reference stories

The second step is preparing some reference stories that you will estimate and refer to when estimating other things at the beginning. I would go for at least 20 stories you have previously done in hours and recently developed, and re-estimate them in story points given how the development progressed.

Estimate enough new stories for one sprint in story points before you need to start it

and

START YOUR FIRST SPRINT WITH STORY POINTS

From then on, it’s polishing:

Get an initial idea of the velocity of your sprints:

Hopefully, you use Jira or another similar tool. Work out the number of story points you are achieving each sprint. Focus on the average, not any one individual sprint.

Update regularly:

Update the original reference stories with stories that were let’s say ‘badly estimated’ that took longer than we expected to do and should have had a different estimate towards them.

Don’t over-engineer at the start:

As a PM, it’s very easy to over-engineer and try to project the future.

Here is a list of unnecessary over-engineering activities that might appear logical when transitioning to story points:

Doing a capacity (in hours) vs. story point velocity
Calculating the relative capacity for senior, junior, and intermediate with respect to story points (i.e., I want to know if my junior developer can achieve 5 story points in a sprint)
Trying to estimate bugs, production incidents, regression testing in story points.

And here’s the thing — Don’t do this. The margin of error at the start is too large to actively project or predict the future. What you want to do is reduce the margin of error in the sprint delivery on average. The most impactful part of that is (unless you are in a holiday period):

How many story points you are planning for the sprint
How many are leftover from the previous sprint (be very very careful about this, more later on)
And how mature your story point estimations are.

Retro the concept constantly

Get your developers and your clients’ opinion on it, but don’t act on it too rashly. If there are small improvements to be made, do them, but don’t cancel the trial period-> you need to crawl before you can walk.

And keep going and delivering.

A few notes from our experience:

What to do with sprint leftovers from the previous sprint.

There are two approaches:

Use the original story point estimate (Conservative)
Make an informed guess on how much is left and use that number as the basis of the next part of work done (but don’t update the estimate) (Optimistic)

It’s really up to you. We’ve used both in different scenarios.

When work for example is in progress (the development work hasn’t been done) we have used the conservative estimate.
When work has been in testing or acceptance, we have used a more optimistic model.

What to do with the leftovers from using hours:

Things like Placeholders-> time allotments for things not related to the actual sprint, but important to get done i.e., ad-hoc tasks, sprint ceremonies, etc.

Don’t put a story point to anything that’s not a story. Keep the placeholders, don’t put an estimate towards them, and they will put an automatic small drain on your velocity. You can reexamine over a monthly or quarterly period if these placeholders are taking too much actual time.

When should I convert to time:

Convert to time only on monthly, or even quarterly periods. Quarterly is better if you can manage it.

Some last notes from our experience:

Every retro we’ve had, we’ve mentioned story points as a positive thing in our development cycle, they put developers under less unnecessary pressure, and focus them on making better, more realistic estimates.

We can also get through more stories on grooming
We can deliver more impactful sprints
And we can notice problems far earlier.

Clients, after the initial period of non-delivery, are happier with successful and delivered sprints.

A few FAQ:

Should I change my expected velocity based on a new or removed team member?

Yes. But it will happen over a period of time, just take note of it.

How can I start in a big corporate segment where everyone uses hours?

The first step with client approval (and this could mean your boss as well) is to get the what and why across. If your work environment is actively looking for positive outcomes and isn’t sticking to deadlines, this approach can work for them. Try to carve out at least part of the product or app in story point sprints and gradually get bigger. There are more scaled versions of this, which is out of scope for this article.

How do you handle invoicing for clients using story points?

There are two ways, either you stick with hours (easier and you focus on the outcome of the sprints) or you can invoice based on a number of story points if you are a mature team (1 year at least doing the project). Remember, don’t over-engineer-> story points are initially here to help developers estimate better. The conversion or other such activities is a much lower priority, at least at the start.

Where can I go for more help?

There are countless articles online in the same context, but if you want more personal help, feel free to email info@ableneo.com -> we would be happy to help you out.

Thanks for reading, and I hope you found this helpful.

The journey from hours to story points on a real-world project was originally published in ableneo Process on Medium, where people are continuing the conversation by highlighting and responding to this story.