Story Points, solution or problem?

 

recently I've seen quite a lot of post describing story points as a mandatory component of the Scrum framework. Besides the fact that the Scrum Guide doesn't mention them and in general any approach to sizing user stories I think that it is useful to highlight few points regarding Story Points :)

First, the person credited with inventing the Story Points, Ron Jeffries, clearly mentioned that they are an obfuscation of time, and although they may encompass complexity, size, risk etc at the end of the day they are a estimation of time need to complete that story. The big difference is that 3 SP doesn't mean 3 hr or days but a similar backlog item (user story in XP) that was defined by the team as a baseline for 3 SP.

Another interesting story about Story Points is that they were invented because of a manager/customer that needed a sense of control on the team's progress.

For those really interested in scope sizing I strongly recommend the Function Points method. It has many flaws but it has few excellent advantages over Story Points.

• It's a measure of size, not time.
• It' s consistent. It can be use to benchmark teams within the same organisation but also  between various organisations and even technologies
• There is a lot of very good quality historical data for planned project, wrongly called "waterfall". This data can be used to measure the benefits of Agile.
• Many metrics derived from Functon Point benchmarking can be applied to Agile: defects/FP, hrs/FP, Project/iteration size in FP etc

One of the areas of improvement in Agile is Metrics. Many teams keep talking about velocity, measured using a relative metric (SP). If the metric is relative the result will be very relative. 

Another issue with Story Points is that they can be very easily manipulated. Nothing stops splitting a 3 points story in 2 stories of 2 points or changing the original 3 in 5. Adding up at a Sprint level the difference can be +/- 1000%.

But there are also many advantages if story points are used wisely. That takes time and maturity.

• keep the estimation, no quotes because it is an estimation rather than a sizing, within the team. Using the story point to impress the PO, SM or any other manager (PO and SM are managers) is wrong and will always lead to gaming.
• use the estimation process as a knowledge sharing opportunity. If there are significant differences between team members then allow time for explanation
• Use the estimation process as a risk identification opportunity. Significant differences are a clear indication that one of the team members did't understood the item
• Use the results to measure estimation maturity and skills for the team, not for the team members. If the time needed to deliver the same item size is similar then you are doing good as a team
• Use the results to improve the process by reducing variability. If the estimation is good then the variance between sprints should be minimal
• Don't assign story points to defects, the user never asl\ked for defects. you better quantify the time spent on fixing defects in each sprint rather than trying to measure defects/SP.