What are the benefits of Story Points
Updated: Dec 1, 2022
I must admit, story points are not my favourite way of guiding the team to help them understand their capacity.
Two reasons:
Firstly, I have noticed there's a habit of converting them mistakenly for time. Let me debunk this once and for all: Points don't equal time (hours, days, months, years), and when we start to convert them to time, they fail at their initial pointing job. It misses the point of points!
Secondly, points far too often get used as a probe by stakeholders to judge a teams' performance. "They delivered 30 points last time why are they not this time, they "should" be doing more, how can we increase their points each sprint" ... etc... it's not your business. Points are owned by the team. Often a result of an immature agile orginsation.
So in a nutshell what is it to "point"?
Ultimately it's a means of estimating the effort on a story. The point represents complexity and knowledge, as the estimate in many cases represents a number (story points; it could also be objects, or sizes … ) it’s a means to weigh how complex the story is. Noting that may be due to knowledge, skills, technologies, etc… And to understand how to point is to understand whether it's either more, less or equal to the effort on the previous story discussed.
My preference to aid capacity planning is throughput. Throughput considers all bugs, tasks, tweaks, niggles, meetings, disruptions... every effort that is incorporated into your sprint. (article coming on this).
Saying this there are some benefits to story pointing, and these are my 3Cs:
Communication
Curiosity
Capacity
Communication
During refinement, the team will endeavour to understand and validate the stories. This is great as conversation sparks, however, sometimes refinement lacks conversation, or perhaps there's more of a monologue and this is where pointing can really aid the team.
Without teams having good conversation at refinement sessions (or at any point), there is an increased risk to delivery and a risk to productive dailies; not raising blockers, working on things outside of sprint, feeling isolated ....
By introducing a betting or pointing system team members are equalised. Voting requires an internal assessment and removes the temporary influence of others, which in turn can build a more confident conversation.
When the points are revealed (at the same time as not to influence others) that opens the story up for more discussion. All voices can be heard behind the pointing. And the "point" is, that individuals can be heard, those with lots of experience can explain further intricacy and or at times miss a holistic view being too close to it, and those with less can bring a different view to the table, and ask the questions that often are so simple that team members with more experience or knowledge may miss.
Curiosity
Through this enhanced communication above from revealing the points estimated, the team naturally start to become more curious about the story. Quieter teams ask more questions and clarify understandings and louder voices start to listen more to others' opinions, creating a safer space to share understanding, and gain knowledge. Here is where a great Scrum Master really shines, enabling an environment with these traits.
Opportunities for those that want to learn are surfaced and teams remember in sprint planning the potential for others to learn. This helps develop T-shape people –Individuals with core expert knowledge have developed a broader understanding and ability to cross over on other topics– this in turn reduces blockers, and gradually can increase speed of delivery. This is a good example of teams slowing down (to learn and grow) to speed up (as they build T-shaped teams)!
Capacity
Lastly, and the more general reason that teams story point is to gauge how much they are able to complete within a timebox (sprint). And at the end of the day, to become more agile is to optimise predictability and control risk, through iterative and incremental value delivery.
This way the team can stabilise their week and over time the team will learn what their consumption and predictability is for a sprint. This allows Product Owners to better plan their roadmap and feedback to stakeholders with more realistic timelines when asked. And if new work is ready for refinement, once refined and pointed there is a better estimate of when features can be deployed.
The aim is to blindly vote at once on how much effort each individual weighs a piece of work. And the aim is not to guess a similar number but a rough number in comparison to others. The magic happens on disparate amounts, the value lies in the conversations that surface when the numbers vary. Don’t aim for a number compromise, you’ll end up with something mediocre. The point of the points is to create a collective understanding of the work at hand, and as a team decide how best to tackle it! (as there is always more than one way to achieve something).
How does this help in planning ahead?
Let's take a team that has been able to on average (velocity) deliver between 13 points over the past 3 sprints.
What does this mean for the team?
The team in sprint planning can bring in up to 13 points worth of work, they feel confident in this and this is motivating. Any more they could fail, or feel overwhelmed and overworked, any less the team could feel demotivated and bored.
What does this mean for the business?
The business is able to see that if there are 20 stories that are all pointed that add up to 100 points, then it is likely that it could take 7.5 sprints to deliver that backlog. If not all stories have been pointed (totally accepted if they are not in a sprint), they could also look at ‘throughput’. Let's say the team have delivered on average 6 stories and 4 bugs equaling 10 chunks of work then this could mean 100 backlog items will take about 10 sprints to deliver.
Second to this if there is a situation where a critical issue is accepted into a sprint once the sprint has started the team is able to remove and agree on which story or stories would need to be removed from the sprint in order for the new critical item to come in. This is based on x no. points in x no. of points out. This should be avoided, and carefully considered as disruption to sprint, increases multi-tasking and disrupts productivity and focus.
Summary
Points are not time based
Points estimates of complexity
Points are not for monitoring the teams capacity
Points are to help the team understand their capacity
Points are not to replace communication
Point are there to enhance understanding
Top Tip
If you notice that you are starting to convert points to time, step back and think, if I look at a previous story’s points; is this less, more or an equal effort? If it's more, ask why? Knowledge, dependencies on others, testing… etc. And of that, gauge is it double that story's effort, the same or maybe less?
Using these questions, and assessing through weight, pointing stories will become an easier, fairer and a far more accurate way to estimate and help teams with planning in the future.
If you want to know more about pointing, and different ways and views on pointing, check out Mike Colns pointing talk: https://www.youtube.com/watch?v=37zfyncCpkA