I had a recent experience with a team that is using story point estimation for multiple reasons and I find it interesting that this team finds it valuable.
Approach from this team:
Items are initially prioritized based on business priority.
The story point values are based on the modified Fibonacci sequence 1,2,3,5,8,13,20,40,100,∞.
The original estimate is based on Development effort and QA effort estimated separately and then added together.
After estimation is complete, the team then prioritizes what they work on first based on the story point value. The higher the story point value, the higher the priority. This apparently is done to provide time for developers to build the software and give enough time for QA to test it in the iteration.
In the next sprint planning, they re-estimate incomplete items based on the remaining effort.
Personally, I see tons of dysfunction with this approach. I don’t see where the value of the software for the customer is being considered. I also see a bunch of waste spent on the practice of estimation in the first place. This is a short post because I am hoping to get some comments from people reading this on if they have experienced this way of using estimation and if they did, what approaches you have taken to work away from this.
Chris Pipito 
One thought on “Story Points Dysfunction”