Question: Re - Estimating with Story Points

Dolores asks: Hi Joe – …I have always been taught that story points should never be compared to time measurements. However, we were using 1 story point = a day or a day and a half of work to estimate initial team velocity. One of the questions we often get about scrum is how do points relate to hours (or days). So, what’s the best answer we should give to our users who are new to scrum and trying to get their heads around story points? (seemed like a good blog topic to me)

Answer:

Let’s start even earlier.  First, Scrum is not trying to track inputs, but rather results or outputs.  We want to maximize the results.

Next: When the Doers in the Team are using story points to estimate stories, they should not be thinking of time.  You are correct.  Try to get them (despite prior experiences) to think simple ‘relatively’.  If the Reference Story is 1 SP, then how big is Story X?  And they use the Fibonacci cards to indicate the relative size.  2x the Reference Story, or 5x the RS, or 21x the RS.

A bit later, all of the Product Backlog (for the next x months, let’s say 6 months..some short period) estimated in story points.

Later still, we want to have a decent guess at when the top Y set of stories (eg, the first release) will be done.  And we have a brand new team that does not have a velocity.  In that case, we have to use that formula that we showed you.  And that formula includes a ratio: 1 Story Point = Z ideal person days.

You are right to be concerned.  Yes, we do not want the estimators (the Doers) to know that ratio when they are voting.  If they do, they tend to go back to the ‘old ways’ of estimating the time to do work (usually in ideal hours or days) and then converting that back to story points.  Not good.

BUT…you (let us say you, as the ScrumMaster), need that ratio to make a decent guess (now) at what the team velocity will be.  So, I recommend that you and an outside person look at the RS (Reference Story) and maybe a reasonable sample set of the Product Backlog, and determine the typical ratio (1 SP = X ideal person days).  Do not tell the estimators (Doers), but use that ratio in the calculated velocity.

Soon, this problem goes away (we hope) because you can use the real velocity after a few sprints, rather than the calculation.

Note: It is normally better if Z is in the range of 1 to 2 ideal person days.  I won’t explain why here, just trust me on this.  It helps some.

One further note.  As we also mentioned, once you know certain information (including the Team’s real velocity), you can start to infer a relationship between 1 SP and ‘real’ time.  At least for a given team.  This is fine for managers and others to do if there are no ‘bad behaviors’.  I do not recommend talking about this with the estimators.  The research shows that people estimate time badly.  But people are fairly good at estimating relative size/complexity compared to a Reference Story.

Everything clear now?