We have being practicing agile development methodologies for a long time as a development company. Most of the time our product owners tries to have a map between story points and time. As a example, they think one story point should be one day per developer. When there is a user story with more complexity (maybe an R&D story) then they are in trouble when we assign a value like 40 using the Fibonacci sequence.

At the end of the day, even we think about our estimates in hours so there seems no point in using story points. What's the best way to estimate based on effort instead?


Estimates are not deadlines.

Estimate complexity in small/medium/large and only offer time based estimates based on how long an item will take to complete once it reaches the top of the priority queue. You will be consistently fairly accurate if you are properly limiting work in process.


Are you practicing "agile" methodologies; or, Scrum specifically? The reason I ask is that you mention Product Owner - not Project Manager. And, in Scrum, the PO shouldn't be too concerned about how long something will take - only priority - because it is up to the team to determine what they can get done during a sprint/iteration.

Having said that, is it possible for the team to do both? Estimate level of complexity, then estimate how long you think it will take.

Another option, and the one I would probably prefer in your setup, is to track how long it takes for an item to go through the SDLC (should probably be tracking this already if you are using a burn-down chart). Track an item from the time it starts being worked on until it is labeled "done" according to the team definition - capture, in a tool of your choice, the task's complexity and total time to complete (similar to estimates versus actuals). Now the PO can look at a task in the backlog and its complexity - compare it to the past performance of the team for tickets of roughly the same value - and get a good idea of how long it should take. (Given the statistic, can't remember origin, that it takes 3 times longer than a developer's estimate to complete anyway, it's probably a more "scientific" approach for scheduling purposes.)

Having said all that, if you are already translating points into time, I would probably abandon the story points anyway.


I work with a simple rule: if it's new and you've never done it before, you probably have no idea how long it will take, and estimates will be impossible.

However, you will be able to estimate just how little you know about it. Here's the scale I use:

5 - this is the first time anyone's done it in the world, or we've never heard of it being done.
4 - someone outside our company has done it before.
3 - someone in the company has done it before.
2 - someone in the team has done it before.
1 - almost everyone knows how to do this.

The more that's known, the more accurate the estimates will be.

I tend to divide the backlog into capabilities; for instance, the capability to trade copper, or comment on a blog post, or take a photo with the phone.

Imagine that you're Kyocera, back in the days before the cameraphone. You're the first people to create a cameraphone. So what do you focus on first? Do you worry about being able to make calls and receive calls, or do you try to see if there's a way of getting a tiny camera into the space?

Of course you do the second, because if you have too much trouble you know you have to rethink your approach, and possibly even abandon the idea. Once you've listed your capabilities, pick the ones which are newest and therefore most differentiating, and do those first. Don't even worry about estimating stuff which is a 5 on the complexity scale! That's a pure spike, and it just means that your project has a high level of innovation associated with it - congratulations!

For anything which is a 1 to 4, David Anderson suggests these buffers for uncertainty:

100% certainty (my 1): 15%
90% certainty (my 2ish): 25-30%
80% certainty (my 2ish): 50%
50-70% certainty (my 3): 100%
<50% certainty (my 4): 200%
my 5: I already told you, don't bother estimating this. You have no idea.

So if you want to have a go at estimating in real days, or you want to map your story points to time, or you already have some idea based on cycle time, then you can use these buffers to determine how much extra to add to the estimate. If you want to add buffers together, then add up all the squares and take the root of that (not all uncertainty will end up being bad).

Now you can do release planning if you want to. But honestly, if you're doing the new stuff first then you'll make the biggest discoveries up-front, and it will be readily apparent if your project is on track.

A couple of hints which will help:

  • If your business don't trust you, then that's the biggest risk. Forget what I said and do something easy and simple so they can see you deliver; then you'll have their trust and you can move to the risky bits.

  • Look out for new stakeholders who might stop you going live, new features, new bits of UI, etc.. Your goal is to get feedback on those bits ASAP. If your team can hard-code data and get feedback from that, do it. Feedback from stakeholders and users is the main reason Scrum works.

  • Sometimes the feedback will be "no", and that's OK because you're getting it early in the project while you still have time to change direction. Make sure your stakeholders understand that they're not seeing the finished product.

  • Forget Agile's rule that "it must be a whole shippable vertical slice". If you can get feedback more quickly than that, do it. That way if you throw it away you're throwing away as little investment as possible. When you get positive feedback, that's the time to turn it into a full slice. Connecting stuff to the database is not risky, for instance; devs do it all the time.

  • If you're going to outsource anything, make it those commoditised bits that are already pretty well understood. Don't outsource your differentiators as it will lengthen the feedback cycle and you'll lose the ability to change direction.

  • When you run spikes, if the developers aren't particularly disciplined then they'll produce pretty poor code. That's fine for the spike, but make them throw it away afterwards. Really good devs who know TDD and tend to produce maintainable code or are good at refactoring can stabilize the spike. Git is a great version system for managing the branches and merging you'll need.

For further reading, try Chris Matts and Gojko Adzic on Feature Injection (the precursor and similar to Gojko's Impact Mapping), Dan North's posts on the Perils of Estimation and Deliberate Discovery, and my post on Cynefin for Devs (Cynefin is pronounced "kuh-nev-in" and is another way of working out the difference between predictable stuff and things you might need to spike out).

Hope this helps and gives you some ideas to try out!

  • Can the downvoter please give me some feedback on why this has been downvoted? – Lunivore Mar 24 '13 at 15:01
  • Padding estimates is a losing game. See student's syndrome and Parkinson's Law. Getting fast feedback is vital, getting fast feedback on something that isn't a representative sample of functionality is false feedback. Product differentiation is great, stack ranking by value is better (of which product differentiation is only a small part). Totally agree with pieces (value of fast feedback, running quick features early to gain trust). – Andrew Clear Mar 25 '13 at 14:19
  • Hm, maybe I should make the go do some further reading stuff a bit more emphatic then. It's impossible to get everything into one small post, so these are just ideas (borne out by experience with a few customers with whom I've used them). Your own assertion that "you will be consistently fairly accurate" is not actually borne out by real project data - see Larry Maccherone and Karl Scotland's presentation at the LSSC a couple of years back. – Lunivore Mar 25 '13 at 14:38

Story Points Aren't Timers

A story point has no direct man-hour equivalent. This is a common misunderstanding of how to use story points. The fact that your Product Owner (you should only have one!) tries to map them that way shows that the Scrum Master has failed to effectively communicate the use of story-point estimation or how to use the Product Backlog for scheduling.

Some proponents do recommend attaching man-hour or calendar estimates to tasks or stories that live on the Sprint Backlog. In fact, a common rule of thumb is that a user story should fit within one-half to two days of effort. However, this is more of a WIP or granularity issue than an actual "story points to hours" conversion.

Points-Based Scheduling

Scheduling based on estimation of effort relies on:

  • Semi-accurate story point estimates within some acceptable limits of standard deviation.
  • A confidence level in your historical performance, e.g. your velocity range.
  • Product Backlog items that constitute (or can be aggregated or decomposed into) a potentially-shippable feature.

So, points-based scheduling works like this:

  1. The whole Product Backlog is given a rough level-of-effort estimate.
  2. The team's average velocity is calculated, or guesstimated if historical data doesn't exist.
  3. Schedules are planned based on how many iterations it will take to reach a milestone at the assumed velocity.
  4. Each sprint, the potentially-shippable feature guides the creation of a Sprint Goal.
  5. Each sprint, the Product Backlog is reviewed and/or re-estimated during Backlog Grooming based on current information.

It's deceptively simple. At no time (other than possibly during the creation of the Sprint Backlog) is a conversion to hours done. Instead, the team uses a measure of its historical capacity to estimate how many iterations it will take the whole team to reach a given milestone.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.