Best practices when Dev Teams relate story points to hours

> What are your best practices regarding
> estimation or how would you advise the Dev
> Team in such case?

Sort the items in relation to each other and the base story you already have (i.e., bigger, smaller, or about the same size). Relative sizing in this way is the preferred method. Absolute sizing is prone to being correlated to time, as you have discovered.

> Is it really "wrong" to derive story points from
> estimated hours?

It's more accurate to say that it's unhelpful. Admittedly a correlation between points and stories can be inferred, because a certain number of points will be inducted into a sprint and the sprint will be of a certain length. However, to attempt an actual derivation would compromise the abstract quality of the points, and shift focus onto the measure. The team might then be held accountable for its use of company time rather than for the incremental delivery of product value.

Sorry for the typo, I meant to say a correlation between points and time can be unhelpfully inferred

Hi,

Scrum is not about what is right or wrong, that is a methodology. Scrum is only a framework.
* First of all I would like to know why you would like to map story points in hours;
* and second I would like to know why estimate in hours is important to you?

Your best option is to educate the team on why relative estimating provides more predictable forecast than estimates in duration.

This is a difficult one, when i mentioned story points to people that have been using scrum for over a year, only one person knew what i was on about. The difficulty is because people always want to stamp "time" on everything and just cant get their head around an estimation so its easier to have an association with time for many people.

This is a behaviors thing and you will come across it in many frameworks or methods.
Even though they really struggle with estimation in hours this totally threw people because it was an alien concept, they really struggled to get the whole point of it, even though its easier to do and the benefits are greater.
Every team is different and although people say they can commit to change many people find it hard so
Depends on the people in the teams you have.
No its not wrong to estimate in hours, as long as your estimations are spot on, but your biggest task will be getting people to let go of an association to time as some people just cannot adapt to the concept.
Watch when you try this with your team if they are fixated with time you will have a battle on your hands, if they can adapt then your onto a winner.

As a Scrum master no one said it would be easy. ;-)

Michael

I am working on coaching the development team to not associate the Story Points with hours. Some are finding this more difficult to do than others as tendency is to relate the story points completed before for the same sprint duration.

For the second question, having the estimated remaining hours of effort is necessary for our team that tracks daily progress. This is relevant to us especially when using burndown charts that use remaining hours such as TFS.

Like Katrina, the teams around me are OK to estimate PBI in Story Point, but since they use tasks with estimate in hours or days to track the remaining effort for their Sprint backlog, they tend to compute a correlation between Story-Point and Days.

What I try to help them going out of that is explaining that the same PBI with the same Story Point estimate can take different time to be done (if junior or senior are working on it ; if pair-programming is used or not...) and that this situation is natural.