Over my history as a manager, I’ve seen multiple teams attempt to adopt story points to varying degrees of success. The real key to making story points work when estimating work is persistence. But keep in mind the below.
Inherent Subjectivity
Story points are inherently subjective. The important thing here is to assign story points for each task as a team. It’s also important to review the actual effort required in a retrospective at the end of the sprint, again as a team. This is the only way for the group to understand the value of a single story point as a currency. Which brings me to my next bullet…
Iterate. Iterate. Iterate.
Story points are really only valuable when iterated on. On day one, every member of the team will have a different value ascribed to a story point. For some individuals, a task will seem like 1 point while others will say it is a 4, others still may say infinite. Iteration is the means by which the team comes to a consensus on how much each story point is worth. Only then do they become valuable.
Balancing The Levers
There are two levers to pull on the valuation of a story point:
- How much work is represented by a point
- How many story points is each individual capable of
The second lever of this is often accidentally overlooked. This is inherently why disagreements arise over story points. A senior software engineer with deep knowledge of the specific work item may feel it is trivial while a more junior team member or somebody with little context will think it is massive.
Finding the balance between the two above levers is critical to making story points work!