Mapping story points with hours

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

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?

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.

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. 

Why?

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? 

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. 

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 :)

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?

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!

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.

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. 

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.

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.

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.

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 ...

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 

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!

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.

Rajesh,

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.

Timothy , thanks for the explanation. From the other thread on https://www.scrum.org/forum/scrum-forum/17099/how-calculate-sprint-user…

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 scrum.org is that hourly estimates during sprint planning are not required at all ?

Please correct me if I am wrong ?

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.

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.

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.

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.

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.

This is a great short video pointing the differences between Story Points and Value Points. Also a very good explanation why you should not make a from/to between hours and story points, it clearly explains that Story points are used for Relative estimates, while Effort hours are used for absolute estimates. Hope it helps.

Learn agile estimation in 10 minutes: https://www.youtube.com/watch?v=Hwu438QSb_g

Learn agile estimation in 10 minutes: https://www.youtube.com/watch?v=Hwu438QSb_g

This is a great video. Thanks for sharing Guilherme.  So it clearly states that at the beginning of a project during the first sprint, we really don't have clear estimates and no idea how many story points will be completed during a sprint.

So at the first sprint it is just an educated guess based on experience of the team. Post that however when we look back at Sprint 1, we can calculate the velocity and this forms the basis to more appropriate estimates for future sprints. So actual estimations only start happening after the first sprint assuming the team is working together for the first time. 

While the common wisdom is to avoid using hours for estimates, it can be useful to translate back to hours as a matter of fact. Let's say the team has delivered task estimated in 10 story points and spent 15 man-hours. Another task, also estimated in 10 story points, required 30 man-hours. Updated velocity will balance it out but why estimates and the actual time varied that much?

Another case when it can be useful is normalization between teams. Let's say the company has a product with two teams. Story points between teams are not and should not be comparable. Derived from velocity, team A spends 10 man-hours per story point and team B 20 man-hours. The program backlog now can be looked at as follows: Team A, 100 story points (1000 man-hours); Team B, 80 story points (1600 man-hours). Now it is comparable as a snapshot in time (of course as teams deliver, velocity and translation to man-hours changes).

Have you ever thought about using "Three Point Estimation" instead of Story Points. With this technique you get 3 estimates from at least three different developers, and you are able to calculate the standard deviation. If the standard deviation is higher than a predefined value (e.g. 10% of the weighted average) - You have to discuss it in the team and break the user story down in two or more an then reestimate. (it was the short explanation - Of course there is more to debate)

The product owner (the customer) have to pay for the deliverables and he/she are of course interessted in value in time and money - more than poker planning and story points (often seen as pseudosubjects for the client).

Story Points are intended to make team estimating easier. Instead of looking at a product backlog item and estimating it in hours, teams consider only how much effort a product backlog item will require, relative to other product backlog items.

From below thread from Scrum.Org https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating 

When we give the team a range to choose we are killing the ideal way of doing estimation in Agile. When the team will start filling those hours against each user story they might not be able to justify  and with hours we won't be able to gauze /figure out the challenges which are team is having as everyone in the team is the end of the day logging hours  and trying to match with what they have estimated. 

Whereas when we do estimtion following story points our thinking towards more on below points before estimation a user story 

Risk

Complexity 

Uncertainty

Effort 

Before starting the story point estimates talk to the team and explain them by giving certain examples  (example - constructing a 5 story building vs 10 story building ) as it may warry and effort, tools, risks, complexity will differ in 5 vs 10 story building. 

Define your base user story explain it to the team and ask them to use as a reference user story and play the estimation game. If it's still not convincing for the team. 

You can look for T-Shirt size or bucket size estimation where you can map the T-Shirt size with story points at back but don't share with the team. It's good to follow this technique when you are introducing estimation to a new agile team. 

I think We all speak about time, no matter we play around but eventually, we go back to a time when we say 

Sprint is two weeks

OK, trying to be realistic here...

Can you correlate story point with actual time? Yes, you absolutely have to. With all the will in the world, regardless of which model, framework or developmental approach you take, at any given point the business wants to know when something will be delivered, right?

So, when your teams are estimating the effort involved in developing some work, if you use relative sizing such as SPs, what does that mean to the business? Nothing. It doesn't tell them when something will be delivered. So, you have to relate SPs to time. Appreciating the fact that it's different for individuals, teams, etc. And, that it is just that - an estimate.

So, over time, an stable, experienced Agile team could confidently say that a user story with a relative estimate of X will take X long to develop, test and release. Which begs the question, why not just use time then? Well, people are inherently bad a time estimating. There are pros and cons or using both relative and actual estimates - just be aware of what they are, and be transparent.

Teams shouldn't be slammed by Agile purists for trying to relate relative estimates to time - if it helps deliver value, it helps. Right? 

I don’t know that this is about people being Agile purists as much as it is about sharing learning and experience. Many folks in this community have experience from each end of the delivery spectrum and I would say the intention of most is to share what they have learned.

Given this is a Scrum forum, some of my thoughts from a Scrum perspective…

In Scrum we don’t talk in points. We no longer talk in estimates. We talk about size and sizing.

Size takes into consideration the various dimensions associated to work such as complexity, risk, repetition, unknowns etc. without the potentially wasted effort associated with estimation. Size can be used for quick relative comparison of backlog items and in comparing to the length of a Sprint. We can have conversations like “Is this too big to fit in a Sprint? Let’s look at splitting it or adjusting scope”. Size can be used by Product Owners to decide if the effort is worth it to achieve the associated value. Size can be represented in whatever a team deems most appropriate be it points, time, t-shirt sizes, fruits or whatever.

Scrum also has focus on Lean thinking and removal of waste. Pushing for precise estimates, such as days or hours, usually requires more upfront planning, which increases the overall amount of time it takes to complete work. Spending too much time on estimation can be a form of waste, and there are diminishing returns on time spent estimating vs. actual accuracy gained.

“the business wants to know when something will be delivered, right?”

Right. In Scrum we work in Sprints, which means “the business” can expect value to be delivered on a regular cadence. If a backlog item of interest is part of the Sprint Goal, the “when” will fall sometime within, or by the end of that Sprint. If the team is unable to complete work within that Sprint, we discuss that at the Sprint Review and share any challenges associated to the work with the business and stakeholders collaboratively. If that work continues to be part of the goal, the business knows the team is focused on delivering it in the next Sprint. 

Jumping out of Scrum and looking at this point…

“So, over time, an stable, experienced Agile team could confidently say that a user story with a relative estimate of X will take X long to develop, test and release.”

If the work is fairly consistent then this could apply, but I feel it may be less about the experience of the team and more about the complexity and variability of the work. An experienced mechanic is likely to struggle with estimating how long it will take to bake a cake if they have never baked before. If it is another car to fix, then yes, they can likely estimate with more accuracy. 

However, if the work is complex where more is unknown than known, then even an experienced Agile team will be challenged by variability in their work and in knowing how long it might take to complete work they have never done before.

The idea of story points is to make estimation in relative units rather than absolute units like time. This allows your team to avoid confusion when selecting stories for an upcoming sprint. Same story will take different time for different team members but it'll be same size in terms of story points. To make story points work your team needs to decide how big is one story point. To do that just take the smallest story and say this story is one story point. And then all other stories should be estimated in terms of this smallest story.

"Same story will take different time for different team members but it'll be same size in terms of story points."

I am trying to take Agile seriously, but that comment makes it really difficult. I am trying to help (as a Product Owner) my team estimate "story points" and then help them understand that even though story points shouldn't be seen / used like "units of time", there are a fininte number of them (story points) that must fit into a "Sprint" which is . . . time. And for us, that's 2 weeks. So a new developer might take 16 hours to develop a given function, that an experienced developer can produce in 4 hours. So the story should have the same number of story points regardless of who it's assigned to? Or if both the new and experienced developers have to develop 4 of these functions during a Sprint . . . I am lost.

there are a fininte number of them (story points) that must fit into a "Sprint" which is . . . time

Must they? The commitments in Scrum are to a Product Goal, a Sprint Goal, and a Definition of Done. Fitting story points into a Sprint would be an odd commitment to make.

Developers don"t have to use story points, or indeed to estimate individual items at all. Estimation is only a guide. If Developers can look at a set of Product Backlog items during Sprint Planning and say "that's about the right about of work, and a reasonable forecast for a meaningful Sprint Goal", then that's fine. They could just consider the work in aggregate and we would expect nothing more. Everything else in Scrum reduces to value delivery and empirical process control.

So the story should have the same number of story points regardless of who it's assigned to? Or if both the new and experienced developers have to develop 4 of these functions during a Sprint . . . I am lost.

Story points is used to estimate the work and not the time. Consider an example of travelling from your home to your workplace- If this is the work then it is the distance you estimate using story points and not the time. So the distance does not change no matter who makes the travel. Apply this same logic to the work in the backlog. In a complex problem space where agile is used, it is not possible to estimate in hours and many of the things are unknown upfront and more knowledge is gained as you work. Converting story points to hours basically defeats the purpose of having story points.

Your example is why relative points are preferred over absolute time. It may be true that it takes one developer 16 hours and the other 4, and it would be challenging for a team of developers to agree on time. Yet, they could probably reach a consensus quickly that the relative effort is small, regardless of who does the work. Small might mean 1 or 2 story points or a T shirt size Small.

The other point is that we don't want to tie a person to a Product Backlog item, as there is no guarantee that the person providing the four hours will do the work in the Sprint. Maybe he or she is on vacation or gets sick. It may be all of the Developers swarming on the Product Backlog item.

To start with, there can be 2 types of estimation - relative and absolute. Relative is when team faces multiple items with similar SOW and can compare with each other. Also, in this case, team cannot exactly commit the time taken to complete the item. 

For absolute, the team is experienced enough to mention the exact time taken to complete the task. Hence, they can convert that into hours. 

In any case, as many of them have pointed out, it's a tricky matter to map story points directly with hours. Now as per my experience, just for better management (and for management purpose :P), we map in this way: - 

US --> working day.

1   --> 1

2   --> 2

3   --> 3

and so on. We usually split the stories exceeding 3 working days. I have a matured team w.r.t Scrum so it works for us. I am not a strong supporter of relative estimation (T-shirt sizing) for my own reasons. But above mentioned have worked till now. Hope I made some sense.