Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
Best practices when Dev Teams relate story points to hours
Last Post 25 Feb 2014 03:23 AM by Olivier Ledru. 7 Replies.
Most Recent First
You are not authorized to post a reply.
20 Feb 2014 01:26 PM
When assigning story points, we use a base story to ensure that estimates are consistent. Still, some members of the Development Team tend to associate story points with the estimate number of hours it take to solve it. What are your best practices regarding estimation or how would you advise the Dev Team in such case? Is it really "wrong" to derive story points from estimated hours?
20 Feb 2014 02:21 PM
> 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.
20 Feb 2014 02:26 PM
Sorry for the typo, I meant to say a correlation between points and time can be unhelpfully inferred
21 Feb 2014 09:44 AM
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?
21 Feb 2014 01:50 PM
Your best option is to educate the team on why relative estimating provides more predictable forecast than estimates in duration.
22 Feb 2014 03:35 AM
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. ;-)
24 Feb 2014 12:37 PM
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.
25 Feb 2014 03:23 AM
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.
You are not authorized to post a reply.