Story Point

Adopting Story Points as a measurement tool is now one of the anti-patterns in the Scrum world nowadays. However, many product teams are still using this. The majority of them, even worse, emphasise the accuracy of their plan by comparing the estimated story points with the actual completed story points. They’re afraid of carrying over the unfinished Product Backlog Items and upsetting the stakeholders. The more time the team spends in planning, the less time they can work on the actual items. Their overplanning creates an illusion that they know everything about the upcoming Sprint. When it deviates, they feel nervous and only think of fulfilling the estimated story points. In the next Sprint, they put even more effort into planning. ...

When I first practised Agile on my old team, one of the things I learned from the consultants was Story Points. Since then, it has been used in many product teams in my company. As all the teams use Scrum as the main framework, many colleagues even misunderstand Stories and Story Points as Scrum ideas. They’re actually from Extreme Programming. Stories Points were invented by Ron Jeffries, one of the three founders of Extreme Programming. They were invented to abstract from hours to complete an item. With the Fibonacci series, developers can easily say the bigger the Story Point is, the more complex the Product Backlog Item is, and the more uncertainty in developing the Product Backlog Item could be. Developers can use empiricism to vote for the size of a Product Backlog Item. With the aid of the velocity trend, they can select the Product Backlog Items into their Sprint Backlog. ...