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.
Additionally, people work at different speeds. Two people could be given the exact same task and one person will inevitably finish earlier than the other. So if your team is estimating in units of time then there is already a baked in error.
Don’t waterfall your Scrum. How accurate are time based estimates? History, human nature, statistics and lies (but I repeat myself) tell a sad story about the reality of waterfall / traditional estimating techniques and patterns. Ever had that project manager come by and demand you provide a list of your work breakdown with time estimates for each line? High and low? Ever get PERT-ed?
Was time allowed in the project managers plan for you to do all the estimating? How often did you bake in some extra time to account for risk and PM hassle? Tell the truth!
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 or team. For each team, a natural (normalized) velocity will be established over time as the team develops an equilibrium and historical body of evidence from which to determine values on future stories.
I recommend reading other articles on the subject.
One thought on “Agile Moment: Equating Story Points and Time”