#relative estimates

Why it's a bad idea

As well as being useful to predict when groups of features will be complete, velocity is also useful as a measure of effectiveness.  If you are inspecting and adapting it is expected that your velocity will increase over time.  The problem with aligning story points with hours is that a sprint has a set number of hours inside it.  If two weeks is equivalent to 20 points, then a two week sprint will always be 20 points.  You'll lose the ability to use velocity as a measure whether your team's effectiveness is improving or deteriorating.  Information like that is too valuable to just throw away.

The second reason for not aligning story points with hours is that it's actually less accurate.  Many people are surprised by this.  They think that if they can think of all the tasks that need doing with all the details they'll then be able to work out an accurate time estimate.  Unfortunately, creative and complex work like software development doesn't work like that.  There are almost always tasks that won't be thought of, unexpected questions and decisions that won't come up until the work is started.  Luckily, these unknowns are distributed across stories based on their complexity.  So if we estimate using relative complexity, our estimates will be more accurate.

Humans are much better at estimating relative sizes than the absolute anyway.  As an example let's say that I asked you to estimate the height of the tallest building in this picture.  I bet you barely know where to start.  Some of you might have started trying to count floors, but you just don't know enough detail to even get that right.  If I asked a group of people to estimate it, there would be a huge range of values with very low precision.  However if I told you the height of any of the buildings around it the accuracy and precision would immediately improve.  We call this a yardstick value.  A value which other items can be relatively measured against.  

 If we return to user stories, it doesn't matter if the yardstick value that I gave you is 'wrong' because it's a relative value.  In fact it can't be wrong.  We'll be measuring our velocity according to this relative yardstick so the system is self-sustaining.  If we equate story points to time though, then it would be possible for the yardstick to be wrong, which is why we need to be so careful not to do that.

Once we have the relative size we can use our historical velocity in story points to determine the approximate length in sprints of a release made up of user stories.  Of course it's important to remember that no matter what, estimates are still estimates.  If they were always 100% accurate we wouldn't call them estimates, we'd call them measurements.

Techniques to avoid time based estimates

1. Make sure you've explained to the developers everything above so that they understand the theory behind things.  Developers aren't stupid, they can correct their own behavior if they understand why.

2. Have yardstick stories from previous sprints available and visible to everyone in the team.  If you have no previous sprints then compare it to other previously estimated stories.  You can ask questions like "do you think it's bigger than Story A" or "is it about twice as complex as Story B?" to get team members thinking about things in relative terms.  In time they'll start doing it themselves.