We Need to Convert Story Points into Hours
Story points are used for relative estimating. They rank the complexity of one item to another, not the time it will take to complete the item. The relationship with time is that items which are more complex tend to take more time to accomplish. There is no reliable conversion to hours.
1 story point is a tasks with a low enough complexity that can be accomplished by someone working alone reasonably in 1 day. What's is 20 story points? You tell me. It's 20 times more complex, but might take 5 days or 40 days to finish. Does knowing that 1 story point should be able to be finished in one day help you make a conversion? Not really.
Does knowing that it takes 10 minutes to drive to a place tell you that it will take 100 minutes to drive to another place that is 10 times as far away? It might if the path to be traveled is equally complex, but what if part of the path to the second destination must be done on foot, or by plane, or is at the bottom of a cave or the top of a mountain? The distance of the journey tells you a lot, but it may not be the only factor (or ever the most important factor) in determining the time the journey will take.
If you want time, estimate in time. But be careful, we use story points and complexity because it's a good way to get started. When a team first sees an item it's fairly easy to say, "I don't really understand that item but my sense is it's 5 times as complicated as this other one." So relative to the other item which we scored a 3, this new item is 20 story points.
Knowing that the first item is 3 story points does not tell us very much about the number of hours a 20 point story will take - we know that the team think it's about 5 times more complex.
As the team learns more about an item they reach a point where they understand it well enough that they should be able to say it should take 30 man-hours. Hopefully they know this before or during sprint planning (if they are using scrum). But that comes from breaking the item down into tasks and estimating the hours for each task. This can be very time consuming.
Relative estimation is a way to get a sense of the size of the backlog early rather than later, trying to equate it to hours is foolhardy early in the project.
But don't wait too long. You need estimates for project design. (for more, see "accurate estimating" below)
...more
