Team is estimating story points, business wants actual time

Question

I'm sure this is not an uncommon theme. We have two scrum teams that are doing an okay job of estimating user stories using story points (the current team constellations are only about 8 months old, although the team members have several years of scrum experience). But it's hard for the business part of the company to relate to user stories; they want actual time units (or "a formula to convert story points to hours") so that they can make a plan for when things will be ready ("we need to know by when we can tell customers that Feature X will be in production").

I, and my scrum master predecessors, have of course explained that "there is no definite relation between story points and actual time" and that "story points are used to determine how much the team can fit in a sprint", and I'm sure you can guess how satisfied they were with that answer. They still want to know, in calendar time, when we'll get to that 27th user story on the backlog.

In any case, I have been compiling some statistics, and our SP estimates translate into wildly different actual-time-spent results (as measured by our scrum board software, which keeps track of how much time tickets spend in the "working on" column). For 1-SP user stories, there is of course a heavy bias towards very short time spans (with the occasional blow-up), but especially for 2-SP stories, they're all over the place: there is a factor of 20 between the "fastest" and the "slowest" completions. For 3, 5, and 8-SP stories, the spread is also more than a factor of 2.

This indicates that (a) the team needs to be much more consistent in estimating user stories of (what should be) similar complexity, and (b) the team needs to improve their accuracy in time reporting (ie. remembering to move tickets out of "working on" when they're in a meeting, at lunch, or playing foosball).

I have plans to improve both (a) and (b) but I feel that's not enough, that the business expects "more concreteness" than what these initiatives will yield.

What are some good strategies in appeasing the business side, so that they will not interfere too much in how we work (eg. by imposing the use of separate time tracking, which IMHO would be dumb because it would in any case be less accurate than the current "automatic" tracking), while at the same time allow them to obtain some measure of concreteness for when stories will be done?

(Historically, during planning we did break down user stories into work items which were then individually estimated in actual work time, but what I'm talking about here are the user stories on the back log that will not have that level of detail or break-down.)

Update: My manager had a hunch that there was a sort of bell curve distribution of hours-spent-per-story-point, but the data I collated and the graphs he made thoroughly disabused him of that notion. :-)

Answer 1

You are correct, there is not a formula to convert story points to hours. You can get a pretty lossless conversion of meters to feet, and vice versa, but you can't say a 3 point story will take X hours, so a 5 point story will take Y hours (solve for Y).

HorusKol touched on this next part. Your sprint velocity as a team can help out with the longer term deliverables. Say your team is at 50 points per sprint, and each sprint is 2 weeks. So 50 points per sprint multiplied by 50 weeks in a year (assuming people take 2 weeks off for vacations) then your current team can do a maximum of 2,500 points in 12 months.

So the business comes up to you with 170 points worth of stories and epics. Divide that by the team's historical velocity of 50 points (an average of every sprint so far) and you get 3.4 sprints. Since we are doing an estimate, round that up to 4 sprints: 8 weeks. Two months, basically. I also like to take the last 3-4 sprints and take another estimate. Let's say your team in the last 3 sprints has done 53, 67, and 55 points respectively. That works out to 58-ish points, which at that rate is 2.9 sprints — so basically 3 sprints. Looks like your timeline for those 170 points is looking like 6 to 8 weeks.

Tell the business 2 months. Don't tell them 6-8 weeks, because they will just hear "6 weeks." Don't even tell them 8 weeks, because most months have about 4.5 weeks in them, and when people hear "4 weeks" they instantly think "1 month." Once an estimate hits about 4 weeks, it becomes 1 month. Then just work in months. If you hit a year or more then honestly just don't estimate that work. It's pointless. Too much can change in a year.

I've found this to be a fairly accurate way to convert story points to hours... well time, anyhow.

You'll get a variance in the amount of time it takes individual stories to be completed. Some developers work faster than others. Putting all the story points into a bowl and turning the blender on to work with averages helps alleviate those inconsistencies.

Oh, and don't forget the most important part:

Round up. Always.

Answer 2

You probably already have some inherent conversion from story points to time estimates - how do you decide that you've picked enough work for your sprint? You've probably said something like "the team can handle 20 (or 40 or whatever) points a week". After a few sprints, you should be able to revise that based on completion - so now it's 15 or 25 (or 35 or 50 or...) points a sprint - this is your team's velocity.

For 1-SP user stories, there is of course a heavy bias towards very short time spans (with the occasional blow-up), but especially for 2-SP stories, they're all over the place: there is a factor of 20 between the "fastest" and the "slowest" completions. For 3, 5, and 8-SP stories, the spread is also more than a factor of 2.

Some variation on time to complete specific stories is okay within points values - velocity looks after that uncertainty by being an average over recent history.

However, you may need to take a long hard look at how you're assigning points, especially those 2-pointers if you're getting such a large fluctuation. Higher point tasks are supposed to be uncertain (and should be broken down) - but tasks as small as a 2-pointer should be fairly consistent.

Since all tasks assigned the same point value should need similar effort, it doesn't make sense that there is such a range of times to complete.

So, look at the 2-pointer that took the longest in your retrospective. Why did something that probably should have maybe taken a morning turn into a 10 day slog? Could something have been flagged on that first morning to say "this needs to become and epic and broken into smaller tasks"? As soon as that happens, of course, the extra work needed should be put into the backlog and not interfere with the rest of the sprint.

Also, try and see how the team underestimated that item - could you do better on future items having reviewed it?

Yes, the delivery date will be pushed accordingly, or the list of features for an update could be revised so the delivery is unaffected. But the aim is to improve future point estimations, and also to get a more accurate timeline.

Answer 3

It is like the weather forecast: the further away, the less reliable. That is an analogy everyone would understand. Errors in estimatons add up.

Sales must learn to talk in Scrum terms to customers. Scrum does not make sense in isolation, it is supposed to be applied vertically throughout the company and preferrably extends into the client realm.

You as a development team should be firm on this. You can give them expectations and guesses but do not let it be commitments that extend a single sprint.

Answer 4

I do a few things when I get questions like this.

Firstly, I answer questions about the future by describing the past. I would say something like We get through about two of these stories per week. So, if nothing changes, we expect to be done with story 27 in about 14 weeks.

Secondly, I want the customer facing people to take responsibility for trading schedule vs risk. I would say something like Remember, the engineering team works on the basis of 50/50 estimates. If nothing changes, there is a 50/50 chance of feature 27 being ready in 14 weeks. Presumably you don't want to report something with that level of risk to a customer. Do you want me to work out an estimate that we have, say, 90% confidence in? You'd then need to review your historical evidence and say something like: There's a 90% chance that story 27 will be done in 25 weeks.

Lastly, remind your colleague that once he makes an external commitment the company is pinned down. Making external promises about story number 27 takes away all the company's agility. You would then be committed to a particular course of action. Whenever someone comes to you with a change request, you now need to answer We have committed to finishing story 27 before x date. I can only make this change if you contact the customer and tell them our commitment is no longer valid. Basically, making specific commitments for work more than a month or so into the future comes with a lot of problems.

Answer 5

You already have a (very crude) conversion:
Scrum sprints are (usally) two weeks.
You know you can finish, let's say, around 20 story points worth of features in those two weeks (or how else do you determine what & how many features get packed into a single sprint?) and your previous sprints confirm that estimate (let's say you finished 18, 21, 23, 19 and 20 story points worth of features in the last five sprints).

Let's say feature X (and all its dependencies) have been estimated as 47 story points.
So you can estimate that if you put implementing that at highest priority you should take around 3 sprints, i.e. 6 weeks (but make sure that your estimations take into account who can do what - if 35 of those points are DB work and you only have on DB guy you need to revise your estimated velocity to take that into account).

That said - firmly communicate that those are crude estimates - there is a reason why sprints are two weeks and not six. The more things your forcast needs to cover, the more uncertainty and error slips in. Also firmly communicate the cost - i.e. that this would mean putting the task at top-priority, meaning no other tasks get worked on. Otherwise you might run into the scenario of:

"When will feature Y be done?"
"If we focus on it next... 12 weeks"
"12 weeks?!? You said it would take 4."
"Yes, but you told us to prioritze feature X, which we told you would bind all our resources and take 8 weeks."
"Can't you work on feature X and feature Y at the same time?"
"groan"

Answer 6

Sprint is defined time, say 2 weeks. You cannot predict some story will be done further than 2 sprints, like you have your current sprint and next sprint. I assume you have prepared stories that are discussed with team for next sprint and were prioritised by business. So best you can say for sure are next 4 weeks of work.

Everything further than 4 weeks is subject to change and business can make roadmap that is not set in hours. That should be planned per sprint, let say some epic1 (epic as in jira bunch of grouped stories) and epic2 should be done in sprint 47 and 48 and epic3 should be done in sprint 49. Epics I estimate roughly in hours on my own to see if one or two will fit in a sprint, timeline is going to slip anyway. If features are not working business have to cut scope or accept not perfect solutions that can be improved later as needed (that should be agile, embrace reality instead of following plan).

You can make nice Gantt chart (that is what business like) with future sprints and main topics/epics for those.

I like to make release every sprint and then I prepare release with what was finished in sprint (or stuff that was signed of for release by business even though was not perfect), unfinished stuff goes to next sprint. This way I have predictable delivery in around 2-3 weeks timeline (one week for eventual fixes on release candidate).

That is my experience with small team, small amount of outside dependencies and what I believe reasonable business. Your milage may vary.

Answer 7

For new features it is nearly impossible to estimate the required time.

Experience with software development shows that in most cases there are details which you cannot see before really starting development. In a best case those deteils may require some additional time, but in a worst case the project also can fail. The reason for that is the complexity of software development itself.

This is the reason why SCRUM only estimates the complexity of the problem (story points), but not the time. The only chance which you have is splitting features with high complexity into smaller ones. This way you can minimize the risk.

As a time estimate is nearly impossible, there is no formula converting story points to time estimates. The velocity can only be a very crude estimate, not more.

In SCRUM, the product owner can change the priorites of the backlog items before each sprint. Therefore the SCRUM master cannot give any estimates for more than one sprint. He does not know which backlog item may become important in the next sprint.

SCRUM is not a method for doing impossible things (plan the unplannable) or making development faster. It is an early warning system if development is running out of time. It allows to react quickly on new requirements.

To the initial post:

You are already very good if you manage splitting most of your tasks into 1 SP to 5 SP stories. The velocity estimates might get better if the tasks are similar and your team gets more experienced. But if there are always new, unkonwn parts in new items, you have to live with the inaccuracy.

As your developers normally spend some time with non-development work (e.g. meetings), you should not plan with 8 hours of development for each day, but less, e.g. 6 hours. Then you get a reserve for other tasks or for work items taking more time.

If your business colleagues want to have accurate estimates (which is a contradiction in itself), explain them the inherent problems of software development. Then show them the advantages of agile methods.