The Dynamics of Story Points
When I first started using story points, I focused on getting a relative measure of task size. Sizing gave me enough data to plan better and forecast delivery. In the past weeks, I started observing more dynamics of story points that I find more significant, so I am sharing them.
Uncovering the Unknowns
It's a more obvious one from the start, but it's still beyond just sizing. When people use a different number of story points during estimation, one of two scenarios is happening:
- The team needs to go through more issues together to understand how large the tasks are and how story points apply to them. More issues to calibrate against are going to do the trick.
- They have a different understanding of the issue and its solution. Knowing there's a difference allows the team to fill the gaps of information that some team members might have (part of the implementation, testing requirements, etc.).
When it comes to the second point, the team should sit together and help everybody understand the requirements. Such exercise builds shared knowledge of the team and makes the team more efficient in the long run since people will understand different aspects of the product.
Consistent Delivery via Constant Learning
When I first introduced story points to one team, they asked me: "should everybody just take 7 story points for the sprint, and that's it?".
People tend to stick to the managerial "consistent delivery" part of agile without realising the enabler for consistent delivery is constant learning. To learn, we need to invest time that doesn't directly (at least not immediately) benefit the business or the customer.
As a senior, you might blast the 3 point task in a day, but it might take much more for somebody who's learning. Why is this important? It reveals the bus factor and gaps that the team has in its skills on the individual level. To be consistent in delivery, we need to continuously invest in giving tasks to people that can learn from them and help them gain the skills, so the project won't stop the next time the senior goes for a vacation.
The Threshold of Growth
The last item on my list is about the observability of how complex can solutions become and why team members inevitably specialise along the way.
If we let people estimate and explain, some topics will naturally become too broad for everybody to understand. Some will mistake this for the disinterest of team members, while the truth is, the team's issues just became too big to fit in a single head. The specialisation can naturally translate into a division of interests in a team.
There are times when we can't divide — lack of a new leader, shared responsibilities for solutions, the possibility of overwhelming the first team, etc. In such cases, it's good to recognise such members and let them handle their specialised backlog instead of doing refinements where only half of the team is engaging at any time.
Summary
In the end, I find the sizing itself as the least-important benefit of using story points. The fundamental importance became learning through discovery and communication.
