Story Points. Are they just an illusion?

I am a very strong supporter of agile development, as my teams have had very strong success in the past.  I have noticed however that point estimates have become very “uncool” in the past 6 months, give or take a couple months.  The reason this seems to be happening, is that management still wants time estimates, so they have taken to converting a teams velocity and dividing by days in a sprint and voila, they have they time estimates.  So as far as management was concerned, story points were an illusion to get developers to think they weren’t actually providing estimates.  I’ve seen this done, and the outcome wasn’t very pretty.

The problem with this approach, is that not all stories are created equal.  Something with a “high risk” evaluation may have low work volume, and vice versa. Something long but easy could have a low points estimate but take a few days to complete.

I saw an article go by on DZone a while back ( http://agile.dzone.com/news/should-your-dev-team-stop ), and it got me thinking about why story points were first used, was it to avoid giving tangible timelines, or was it to try and add more of a qualitative value to the estimates.

The idea behind points, is to estimate how much ( effort, risk, time ) a specific feature will take to complete.  This point estimate should also take into account the definition of done from a team, which again is completely different across different teams.

I’ve seen point estimates work for 2 companies now, both as a developer, team leader and scrum master.  I have not yet been convinced of their uselessness, but am always open to new suggestions that might improve on the process.  They are always subjective to the team, meaning each team has their own scale of points, but overall patterns emerge over time.

do you have any success or failure stories to add?

Scan to Donate Bitcoin
Like this? Donate Bitcoin to at:
Bitcoin 1C3bk51YNGrEFXNy8HxCWs9QMbRkniDjdJ
Donate

Tim Voet has been in the IT industry since 1997. Tim started his career doing tech support and network administration at a large Pharma company. He then spent the next 12 years doing development, leading and managing development teams, mostly in Java, but also some PHP, and Ruby on Rails. Tim has always hands on, and loves challenges that make most people cringe. When he isn't at work, he's spending as much time as he can with his wife and 3 boys. Life can be a busy time with that many young kids. He is currently open to new consulting opportunities, please feel free to contact him with your project information tim - at - timvoet dot com

Leave a Reply

Your email address will not be published. Required fields are marked *

*