Skip to main content

How to transform hours into story points ?

Last post 09:41 am April 24, 2018 by Marie-Hortense Ntobana
8 replies
10:11 am April 20, 2018

I'm the Scrum master of a dev team using hours to estimate PB items. 

We now want to use story points and I would like to propose a correspondence grid for discussion.

This is my idea :

=< 1h     -> 0,5 point

2-3h       -> 1 point

4h          -> 2 points

5-6h       -> 3 points

7-8h       -> 5 points

1,5 day   -> 8 points

2 days    -> 13 points

Am I in the good way ?

Thanks in advance for any help.


10:53 am April 20, 2018

Are the team clear on *why* they wish to estimate using story points, and on what the purpose and limitations of a time mapping would be? Have they thought about also taking into account effort and complexity, for example?


11:00 am April 20, 2018

@ Ian,

In fact we will change the software to manage the PB with JIRA. In JIRA we will use story points for PB items and the dev team will keep hours to estimate sub-tasks, the burdow will track their work using story points. I explaned the dev team effort and complexity.

So, I can answer yes to your both questions.


05:38 pm April 20, 2018

If you feel there's a need for a correspondence chart, it indicates to me that your estimation and measurement system may be unnecessarily complicated.

The first thing I'd look at is why your team feels the need to estimate large items (stories) in points, but then estimate small items (tasks) in hours.  Why are you providing estimates in two different units?  Why not estimate everything in hours, or estimate everything in points, instead of needing to "translate" between them?


08:16 pm April 20, 2018

It is my preference, but I see little value in time estimation of tasks.

Defining tasks for a PBI has definite value, as it promotes further clarity around effort, and gives insight into complexity.   However, time estimates around such tasks introduces unnecessary complexity and waste in my opinion.   

You've already provided a relative estimate for the item, and you've decided to burndown based on those relative story point estimates.   What more do you require?


12:08 am April 22, 2018

Hi, Marie!

When I started to work with points, I did not so specificly as you. In my company, we have this direction:

We work with 2 weeks sprint, and each of member team can do 13 points.

where, 2/3 point is a less complexity, 5 medium, and 8 high complexity. When a story have 13 points, it must be split to fit in a Sprint.

We have one expression in Brazil, something like "This is not write in a stone" that means: This is not a inflexible rule.

But is our own way to do and has worked so far.

 

 

 


02:37 pm April 23, 2018

We don't use Time.. you will become a hostage to fortune. Estimation is a value for the team, just the team.. avoid time. The only time you are interested in is time box of Sprint in our case 2 weeks... so in two weeks well complete the work necessary to meet the goal as set. The individual time on each item, the order we do them and anything else is nothing to do with reports or business. The mark of good is we delivered..

 

If people are getting obsessed with time switch the estimation model.. Try T-Shirt sizing, Pizza or most abstract Dog... In a report or conversation once the Business have to say something like.. "Explain how this piece of work is a Sausage Dog and that one is a Wolf Hound" they may realise how the value/point/number/animal isn't of interest to anyone outside of Scrum Team


06:19 pm April 23, 2018

I would suggest to not worry about a conversion chart of sorts. If the team wants to move to story points, explain that they are not equal to hours and let them go. With time and practice, the dev team will have a better grasp of the time and effort it takes to complete a task of 5 points versus a 1 point task. 

In my experience, if you do a conversion, the team is still thinking in terms of hours; which is what they are trying to get away from in the first place. I think this is a scenario when the "out with the old, in with the new" is the best approach.


09:41 am April 24, 2018

Hello to all,



Thank you for your inputs.

What i retain :

- avoid correspondance between hours ans story point

- talk about story points for all the PBI

- propose a correspondance between complexity level and story points, and discuss with the team

- wait the third sprint to see if the dev team understands how to estimate PBI with story points.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.