Mapping story points with hours

Last post 02:16 pm February 13, 2019
by Eugene M
25 replies
07:07 am April 19, 2017

Hi everyone,

I have just taken over responsibility as a a scrum master and although i have worked under a scrum team before for a year but i always had difficulty in estimating according to story points. So in my first project as a scrum master, I took a risk and though to map story points against hours and it went very well. Here is how i mapped:

Points - Hours

1       2-4

3       4-8

5       8-16

7      16-24

9      24+

When i gave them a range the team was very comfortable so what i did estimated it according to the table above and in the end they all had a rough time frame then when and how they are going to complete it. I need to know that if it is feasible in long run?

Need very valuable comments on this one :)

08:07 am April 19, 2017

If your points are mapped to hours, why don't you just use hours? How do you take complexity, risk and uncertainty into account? 

08:11 am April 19, 2017

The purpose of estimation is to help a team to forecast how much work they can take on in a Sprint. Why though would you need a time-to-points mapping to be feasible in the long run? Once the team have a common understanding of points, why not just use relative estimation from then onwards, and allow other factors such as effort and complexity to be brought into consideration?

10:13 pm April 19, 2017

using ranges in the estimation is absolutely a blunder Idea. lets not put it to the team. please ask team to do it with story points by setting standard hours. I have 10 hours for a SP. if the team have hard time understanding you can motivate team to adapt to new terms or things so that the team would get used to it in just a couple of sprints. or if your team still find trouble in doing that, just estimate with hours.

11:55 am April 20, 2017

Using your scale, how many points would a following task take?

Everyday, throughout the 2-week sprint, run a script in the morning (2 minutes), gather data at the end of the day (5 minutes) and put it into the spreadsheet (5 minutes). Whenever script fails during the day it needs to be restarted. 


01:17 pm April 20, 2017

Thanks for your response but i had an experience in which estimating with story points was not worth enough. For e.g:- there is a task which was estimated for 2 story points and i as a Tester had in mind that it would take the feature not more 4 or 5 hours to be completed but when it is actually worked it sometimes take more than 3 days. How will we handle that scenario? 

02:56 pm April 20, 2017

Use Daily Scrum for it's purpose, that is inspect and adapt the Sprint Backlog to use Development Team's time most effectively.

In your example it would mean, that if task was suppose to be completed after 5 hours, but wasn't, then you should be able to observe this deviation and take necessary actions on the next Daily Scrum.

Tasks in Sprint Backlog rarely follow Gantt chart diagrams made up front. If they did then Scrum and sprinting is probably not the best approach for the product development. 

03:04 pm April 25, 2018

I have a similar issue.  I need to bill our clients based on time (hours) and so it seems that we would need to eventually translate story points to hours.  

Currently, our company is mostly waterfall in that we estimate our work to client in hours up front and then use those estimated hours as a budget for our employees to hit.  For instance, if the developer estimate that the feature will take 3 hours to complete, anything below 3 hours would be on budget and anything over 3 hours would be over budget.

As we transition to an agile methodology, we need to understand how to bill our clients.  Do we provide them with an estimate range up front (e.g. 40-50k) and then just bill them for the actual hours that have been logged by the project team and hope that we fall within the estimated range?

Also, how do we keep the project team accountable?  It seems that without a budget for hours the expectation for how long something should take is vague and open to interpretation which means we lose the pressure to get things done quickly and tasks may take longer if the project team doesn't feel pressure.

I know I've covered a couple topics here but any insight to any of these issues would much very much appreciated!

Thanks :)

04:58 pm April 25, 2018

As we transition to an agile methodology, we need to understand how to bill our clients.  Do we provide them with an estimate range up front (e.g. 40-50k) and then just bill them for the actual hours that have been logged by the project team and hope that we fall within the estimated range?

Why not bill them Sprint by Sprint, assuming that value is being negotiated and delivered in that manner? Wouldn’t that help to keep the team accountable?

09:38 pm April 25, 2018

Also, how do we keep the project team accountable?  It seems that without a budget for hours the expectation for how long something should take is vague and open to interpretation which means we lose the pressure to get things done quickly and tasks may take longer if the project team doesn't feel pressure.

I view this as an issue of trust.   Why don't you trust the team to not only deliver, but also to give an honest effort?

This is indicative of a Theory X management style, where the belief is that workers need to be controlled, and they are inherently prone to under-performing.   Theory Y is a belief that everyone is well-intentioned, and just needs the right environment in order to excel.   Scrum is supportive of a Theory Y approach (teams = self-management).

Daniel Pink's book Drive is an excellent resource for understanding true motivation.   You would be well-served to read it and apply its principles.   And you may be blown away by the results!

08:20 pm November 14, 2018

I do not know if this is a good idea.

A point value for a user story is not a RAW measure but it is rather an abstract measure used for the purpose of obtaining a high level estimation of complexity. In fact, a point should define the difficulty level of a user story by taking into consideration the following:

  • Effort
  • Risk
  • Complexity
  • Unpredictability

We as Scrum Master know quite well that when a task is assigned to a developer that many other factors besides raw effort take hold of the process.

08:16 am November 20, 2018

I don't think it's a good idea from a Scrum Master perspective to go with hours based estimation. Sizing makes more sense to get a realistic way of estimating tasks. Risk and complexity is all taken in to account with an estimation coming from a group during a planning poker session. More over we should be able to measure a scrum team's capacity using sprint velocity. Then only we can go ahead and come up with realistic predictions after a few Sprints. Predictions that this team can burn this many story points for a Sprint. Thus we can prioritise stories and decide which stories to be accommodated in a Sprint based on the team's velocity. 

10:28 pm December 5, 2018

Not to be a troll, but I'm starting to question the value of estimates after watching a few presentations on the #NoEstimates movement. 

I've talked to a number of people who went to counting stories completed rather than points, and the results were about the same and sometimes even better than  pointing or other estimating, given the amount of time spent on those two activities. 

I think the question that has to be answered is whether counting points completed gives us any more idea of our ability to build working software than counting stories? 

I am still struggling with estimating in hours, unless the estimation is done on a continual basis so that any given time, we have a more and more accurate prediction of when something is going to be completed.

If the team is able to be transparent with each other, then if something is being held up because someone is stuck, then the person doing the work will be confident enough to let people know and raise the impediment that they need help with during the daily scrum.

05:11 pm December 6, 2018

I'm starting to question the value of estimates after watching a few presentations on the #NoEstimates movement. 

In Scrum, a Product Backlog item will form part of the Sprint forecast of work. Therefore the team must estimate each item at least to the point of understanding that the associated forecast may be completed in a Sprint. If a non-Scrum team is working on the basis of continuous flow rather than sprinting, this consideration will not necessarily apply.

There’s nothing to stop a Scrum Team from refining items to the level that they can be considered of more or less equal size for planning purposes. A throughput-based forecast may then suffice, and it may closely resemble a #noestimates approach where actuals are tracked. Nevertheless, items will still be estimated in so far as they are refined, and the team will be able to express confidence in any throughput projections made.

07:46 am December 7, 2018

To build on what Ian said, a Development Team could ask itself whether an item is small enough to be effectively processed in a #NoEstimates way. The answer "yes" or "no" would be the estimate.

08:50 pm December 7, 2018

What i have readed and sow till now is try to avoid hours mapping, will never match up. Do not forget that team is dynamic and projects as well, new technologies, new ground, people getting sick, people getting demotivated ... this is all that can impact your velocity if you are looking at this (it is optional and what i have seen till now not recommended).

I am currently finishing KANBAN book and what i like in kanban is throughput and cycle time which leads further to monte carlo simulation for predictions ... please read on this maybe this is what you are looking for. 

I recommend doing estimates regardless if you need it for predictions, because if you use kanban trough put system you can identify problems ...

05:01 pm December 9, 2018

I am completely new to the scrum world. I have the same issue. If a story X is estimated for 2 story points by the team. When doing actual development, developer A will take 16 hours to complete this and developer B will take 8 hours as he is experienced developer. 

If sprint velocity is 4 story points and when the sprints starts and if A takes the story , he will work for total 16 hours

If sprint velocity is 4 story points and when the sprints starts and if B takes the story , he will work for total 8 hours and will be free for rest of the time ?

Do we calculate hourly efforts and who is going to pick what story  in SPRINT planning ? so that people remain engaged during the sprint,

how do we handle this situation ? Please help me i am totally confused about the 


10:40 pm December 10, 2018

Do we calculate hourly efforts and who is going to pick what story  in SPRINT planning ?

During sprint planning for the team I'm currently in, the team as a whole provides estimates in hours for each story that is brought into the sprint. This is estimated as average developer hours, as they don't know who will be working on it.

We then compare the total of the hours on the tasks to the total capacity for the team, and when we get to 60-70%, we consider stop bringing in stories into the sprint.

So, I would suggest asking the team to agree on a number they are comfortable with.

Also, you should have enough stories in your sprint for developers to work on. If an experienced developer finishes a story quicker than expected, there is more work that can be done. Optimising for individual time usage is inefficient - it doesn't matter if someone is not 100% utilised if it means the team performs better.

Happy to hear others thoughts on this!


03:12 pm December 12, 2018

To address the problem with the original question - the team not being comfortable using story points in the beginning.

In my stint, I faced similar scenarios where a new team/team member had difficulty understanding the use of abstract SP system of estimation. So I just used T-shirt sizing with 3 or 4 possible values. Once the team got comfortable with speaking about a User Story as Small, Medium etc., I found they were more comfortable in using story points.

Scrum also does not mandate using SP for estimation, use whatever jargon the team feels comfortable with, and then if required, move to SP estimation.

Please correct if my understanding or usage brings any issues that I may not have foreseen.

05:02 pm December 12, 2018


Here is an analogy that may help you understand relative estimating better, and the downfalls of individual hour-based estimation.

Think of a PBI as a large rock, and the goal (DoD) is to move that large rock from point A to point B.   Some members on the team may be stronger than others, and can help move the rock quicker.   Some team members may not be in good physical shape, and may take longer to move the rock.   Maybe one team member has a hand cart to move it more efficiently.   Maybe the road between A and B is smooth, or maybe it is hilly and full of obstacles.

The one thing that doesn't change in any of the above scenarios is the size of the rock.

THAT is what you need to focus on.   Not on how long it my take, but what the effort and complexity is of the item, in relation to other items.   Give it a number (relative estimate), and judge all other items as similar, larger, or smaller than that one.

06:53 am December 30, 2018

Timothy , thanks for the explanation. From the other thread on…

what i got to know from Curtis Slough comments that team shouldn't be worried about who is going to work on what, instead team can make a guess as a whole on how much they can achieve in a SPRINT. 

What i concluded from various threads on is that hourly estimates during sprint planning are not required at all ?

Please correct me if I am wrong ?


04:15 pm January 21, 2019

I have the best experience NOT using hours or days in any way. 
We use planning poker, and we use the Fibonacci sequence for actual story points, meaning the effort needed to complete the story. We know the number of story points we can complete in a sprint, so for every new sprint we just play planning poker, and in my experience, this works best.
The difficulty for people is to let go of the concept of time. As humans, we're really bad at estimating time, but we're good at estimating effort. So estimating how much effort you can put in a sprint works better than estimating how much time you need for each task and then adding it all up to fill a certain number of days in a sprint.
I've never seen it work very well.
Added to that (but a bit beside the question): if you use planning poker, also the quieter people will get their say.

08:34 am January 22, 2019

Yes, it is nice entertainment - using planning poker cards. We used it in one of the projects. Now we are distributed team - this makes it more difficult to use planning poker cards. Luckily, I am not scrum master...

What I heard about the idea of story points - is that you should have some user story already completed as a reference for story point. However when we are just starting as a team we do not have one ! So it is "egg and chicken" problem :)

You said "we know the number of story points we can complete in a sprint". If sprint is 2 weeks, we can say that sprint is equal to 10 story points and multiply it by the number of persons in the team. What is the difference if we just estimate in days !? For me the concept of story points seems not logical but I admit that the world and relations between people do not follow the logic either. Therefore I am open to arguments for using the story points.


03:37 pm January 22, 2019

I'm going to pull a couple of quotes from the Scrum Guide section on the Product Backlog before I give my opinion on using Story Points.

Product Backlog items have the attributes of a description, order, estimate, and value.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. 

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Now my opinion.

No where in the Scrum Guide does it say that Story Points should be used.  It doesn't say anything about T-shirt sizing either.  All it mentions is that estimation of PBIs should be included. It does not say if the estimates have to be effort, time, or complexity.  It just says estimates.  So if your team is struggling with Story Points and feel that they have a better way of estimating that everyone understands, use it.  Story Points are confusing, mainly because there are so many interpretations of how to use them (I give this thread as evidence) and none of them are wrong. And I even see some types of estimation occurring in the #noestimates movement, it is just not Story Points.  It is human nature to estimate effort/time/complexity when discussing something and identifying a way to solve it.  All Scrum really suggests is that those estimates be discussed and captured at some level. 

I do use Story Points with some of my teams but it is because they have come to agreements on what they mean. It is usually complexity and effort.  None of my teams have ever used hours as the estimation mainly because it can vary widely depending on the person doing the work.  But as @Timothy Baffa said on December 12, 2018 with his "big rock" analogy, relative effort can be determined. Is it exact? No, that is why it is an estimate. All you can do is make an educated guess.

So what ever means your teams can all understand and agree upon to capture their educated guess is exactly what the Scrum Guide suggests.

10:56 am February 11, 2019

The Art of mapping User stories to man hours is tricky but indeed it's possible.

Primarily User story points are defined by using Fibonacci series, the series which we can see in the creation of the whole universe.

The Fibonacci series graciously defines the complex nature of building the product or delivering the right product. So user story points ideally define the complexity and efforts involved to design, develop and deliver a product to the main line (production environment). 

Consider an example :

Introduction of a new feature in the IOT(internet of things) device implemented in the banking sector, the function of the device is to collect the 1000 customer based inputs/ minute, process it, and deliver it to the higher database ( a database in general).

Now the new feature development is: instead of 1000 inputs, the device needs to process and pump 10000 inputs/minute.

So what's the scrum development team needs to know?

now I am defining the complexity of implementing the feature. 


1) The internal architecture of IOT device.

2) Load and performance capabilities of the device.

3) Data communication network etc


Scenario :

Now changing a parameter value in the text file of IOT device ex: "inputs = 1000" change it to "inputs= 10000"

and tweaking the communication network will serve the purpose.

Implementation is done it's all over.

Now if the development team does not have enough technical skill set to tweak the communication network and has to rely on another team to complete the implementation of a functional feature + any uncertain events after implementation probably database will not support the insertion of 10000 inputs per minute etc etc.

In general where the system is not completely tested.


In the above scenario, the complexity and risk ( collaboration with other teams and stakeholders) are high but the man-hours needed to implement the feature is low.

i.e poker card complexity number might be 13 (highly complex) but the man-hours might be around 8 hours (rare occurrence though).


My opinion is that :

For proven platform

If the feature development is for a proven platform (i.e all the risks are completely known), complexity is directly proportional to efforts (man-hours).


For uncertain / new platforms 

If the feature development is for an uncertain platform (i.e all the risks are not known), complexity is not directly proportional to efforts (man-hours), its learning curve and conclusions about actual man-hours should be made only after implementation.

No matter how good implementation is analyzed, the uncertainties are always high in new platforms.
















02:16 pm February 13, 2019

As others have pointed out repeatedly, there's no real benefit in converting/mapping story points to man hours. Use one or the other and you've already avoided significant waste.

Also, story points are not defined by using Fibonacci numbers, nor are they inherently linked to it.