How to transform hours into story points ?

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?

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

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?

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?

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.

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

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.

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.