Estimations: Story-Points vs. Hours

Over the last months the topic of estimations for developing software with many people arise many times. The thing with the story-points for estimations often seems to be confusing so lets write about it.

Why Story-Points?

When a software developers makes estimates in hours, others (Managers, Customers, Users, etc.) thinks of it as a more or less exact value. But the problem is, that it is really hard to name exact values in software development because each software and each project is different. So most of a developers daily business is doing things or the variation of it for the first time. Its more like an engineer / research style work then repetitive assembly-line style work. Try to ask scientist how long he needs until finished (in hours)?

So instead of estimate in hours the software industry came up with a new measurement: the Story-Points.

What are Story-Points?

All and nothing! Its a measurement that does not directly result in hours and its values have different meaning for each team! This is a very important thing: one can’t take the story-points definition from one team to another. Each team has its own understanding of the values used.

But really, what is it?

Each backlog-item (aka User-Story aka To-Do) gets a story-point value which describe the approximate size of the work. Backlog-items that are about the same size should have the same story-point value. When the team makes an estimate for a new backlog-item they think of which other backlog-item was baout the same size and give it the same story-point values.

Story-Points describe the relative size of a backlog-item to other backlog-items.

How to use Story-Points?

The questions is what we can do with the Story-Point values if they are no hours and a thing that only the one team understand?

The team works in sprints (aka iterations) of 2 to 4 weeks (defined by the team). After a few sprints the team knows how many Story-Points they can do in a sprint by sum the story-point values of the backlog-items they did per sprint. This values is called “Velocity”. Knowing this value allows the team to plan a new sprint by pulling in backlog-items until the total Story-Points reached their velocity (or even better: a little less). If team-members are on holiday etc. the team pulls in less story-points to address the reduced velocity.

Where come the hours into play?

After a team pulled in the backlog-items for a given sprint they plan the details for each of these backlog-items.

In tools like Microsoft Team Foundation Server (TFS) or Microsoft Visual Studio Team Services (VSTS) the team can add “tasks” to each backlog-item. The tasks are a relative small amount of work not more then a few hours. One can easily do an estimate for it in hours. All tasks together get the total hours needed for a backlog-item. All backlog-items together show the total hours for the upcoming sprint.

Then the team can define work-hours per day and days-off for team-members. This gives the total hours the team has for a sprint. TFS/VSTS can visualize all these values to show if a sprint (and their members) are on-track or go totally off.

Why not directly create tasks and add hours for all work?

Two things:

1. Lot of work: For a medium software project it would take weeks a team spend to get all the detailed estimates in hours. No project likes to spend all this time upfront.
2. Change of plans: In software projects its very likely that the plan will change. That’s why the industry came to “agile” software development but this would be another blog-post. Spending days or weeks making detailed estimates for work that will be dropped before it will started does not make any sense and is a waste of time.

What values to use for Story-Points?

The bigger a backlog-item is the more difficult it is for us humans to estimate exactly. To reflect this many teams use values from the Fibonacci number (1, 2, 3, 5, 8, 13, 21, …) only and limit the maximum value to certain value. Backlog-Items that are bigger then this maximum value must be spitted into two or more separate items.

But really: give me number!

Ok, lets see a sample what Story-Point values my colleagues and I often use:

• 1 = A trivial change with absolutely no risk, should not take longer then 30 minutes
  e.g. changing a static text in the UI
• 2 = A small change with absolutely no risk, not longer then 4h
• 3 = Simple change with low risk and takes maximum 1d
• 5 = Medium change max. 2-3d or small change but with risk
• 8 = Larger change of max. 5d or change with risk
• 13 = Large change of max. 2 Weeks or with a decant risk

Risk: with risk I mean the risk a change takes longer then expected because we don’t know exactly how to do it or we for the first time.

Sprint length: we normally use a sprint length of three weeks. So a value of 13 with a max. of two weeks fits into a sprint well. Larger values then 13 don’t exists for our team because with our scale they would not fit into a three week sprint.

Update: I got feedback from multiple people that even “13” means to them: “We are really unsure about this item and will need to further split it for a better estimation”. So normally the items with 13 will be split to multiple items before work starts on these bigger items.