Mapping story points with hours

Last post 05:02 pm December 12, 2018
by Timothy Baffa
19 replies
Author
Messages
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. 

Why?

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

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.