As a project manager, I am interested in the effort (estimated and actual). While Sprint based estimation is story point based, how can I translate them to effort so that I can track and report them.

Time and again I hear that we should refrain from associating hours to story point; but as a PM I need to track my effort as hours. Am I missing something here?

I thought it would be good to explain why I needed this. This is from two perspectives:

  1. Billing (Client billing needs to be done in hours)

  2. Productivity improvements comparison and organizational base lining.

2 Answers 2


Time based estimating and story point estimating are different concepts. There are two big differences:

  • With story point estimating the team is guessing at the relative size of tasks. For example, Story A is twice as big as Story B. The aim is for the team to do this relative sizing in a consistent way.
  • Story point estimating is a metrics based approach. The idea is to do some work and then measure how long it took to complete. Then use that measurement to predict the time it will take to do future work that is of a similar size.

If there is a business requirement to track effort in time units (for example, if you need to bill a customer for hours worked) then this should be done by logging the time it takes to complete tasks. This would be completely seperate from the story point estimating process.

Keep in mind that this kind of logging of time is an overhead and so will reduce the output of the team. The team may well resist logging time unless they can see a good justification for it.

If you also want to track estimated effort in time units then the team would need to do two rounds of estimating. First they would do the story point estimating (for Scrum) and then they would need to do time based estimating (to meet the project management requirement).

Once again this would be introducing an overhead that would reduce the output of the team. And once again this cost would need to be justified.


You cannot directly translate a story point into an hour effort equivalent. At best a story point is a continuous distribution that represent a range of time values during which a story could be completed.

To say something like 2 story points = 3 days of effort is incorrect.

However it could be true that a 2 SP story has an average completion time of 3 days with a min of 1 day and max of 5 days using a 95% confidence interval.

Whoever is asking for effort values to be derived from story point or velocity values is still thinking in waterfall terms. If you absolutely need to provide effort values, a common method is to decompose stories into tasks and have the team members track their estimated and actual hours against individual tasks.

If you go this route, however, you will find that many team members may complain that it is an administrative burden. You will also encounter padding behaviors. Finally, if you work with certain types of waterfall managers, you will expose the team to micromanagement - something that is generally an absolute no-no on agile scrum teams.

  • As a side note, there is ideally no PM role on a scrum team. The 3 vanilla roles are PO, Team Member, and Scrum Master. Much of the traditional PM work is generally split between the PO and the Scrum Master, with remaining organizational duties based to the general team, where individuals are encouraged to be self-organizing and empowered to go beyond the traditional developer or QA roles. That said there are many great PM's on scrum teams that transition to a servant leadership role and help the greater organization become more Agile as traditional PM responsibilities are taken over by team
    – WBW
    Aug 7, 2015 at 16:29
  • So what would be a good way if a client asks an estimation of the total project cost? There should be someway to transform the SP into billable hours no? Feb 22, 2016 at 16:44
  • No, story points are probability distributions over time so to trying to equate a story point to an exact hour equivalent is impossible. You can use story points to derive forecasts for when a project could complete. Many teams do some form of range-based estimation. So for instance 12-16 weeks with 80% confidence. Teams generally burn a fixed amount of cash over a period of time to its possible to derive a cost range. This assumes the entire backlog is known, which is always false.
    – WBW
    Feb 22, 2016 at 16:54
  • 1
    The trick is to work with the customer to get them to understand that scrum teams focus on incremental delivery of value, and don't assume all scope is known up front. Sell the customer on the team's ability to shift priorities and evolve a backlog of value over time, rather than allowing the customer to pay for a customer using waterfall planning principles.
    – WBW
    Feb 22, 2016 at 16:56
  • 1
    google for the 5 levels of agile planning, that is the general framework that supports longer term planning and what can often be used to drive budget forecasts as well as help you/the client understand why fixed scope doesn't work on Agile projects.
    – WBW
    Feb 22, 2016 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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