Agile Moment: Equating Story Points and Time

Posted on Updated on

userstory

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.

Improvement

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 agile 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!

Conclusion

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 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.

Advertisements

One thought on “Agile Moment: Equating Story Points and Time

    […] also: Agile Moment: Equating Story Points to Time, Scrum Effort Estimation, Practical Guide Story Points Estimation, How Story Points relate to […]

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s