Equating Story Points to Time = Bad

I have found a common recurring issue on some of my Scrum teams over the years regarding equation of time (hours, days, weeks, months) to story points for user stories.


When teams try to equate story points to time remind them the purpose of the activity is to create interaction and collaboration on the team. It is a natural inclination for us (engineers?) to desire to make and solve the formula. However, the value in performing planning poker sessions and the assignment of story points is in the discussion, defense, and debate. The purpose of planning poker is not to create and solve a math problem or create data for a spreadsheet. If engineers were simply asked to assign “hours to complete” to a user story / engineering effort then the collaborative benefit (generally) would never occur. The benefit of planning poker for estimation is derived from its simplicity and effectiveness. When the pattern is followed in earnest, it can produce engineering estimates that are highly accurate.


At the end of the day, it doesn’t matter whether a “13” sized user story winds up equating to one week or two months for a particular engineer. For each team, a natural velocity will be established over time as the team develops a historical body of evidence from which to determine values on future blueprints.

I recommend reading other articles on the subject.