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?