A lot of debate has been going on about Story Points since the day they have been used. The experts are divided almost equally on either side, to use them or not to use them. In Ron Jeffries own words
Now, when I look at the use of Story Points in my career as a developer, Scrum Master or as an agile coach, I have found them useful. I have also encountered many situations where the story points have been used for all the wrong reasons. For example: in one of the organizations where I worked previously a SOW was having a clause that the team will deliver 60 story points of work every Sprint. And this was even before a team was setup.
Now this is the hammer and nail situation. If you see everything in this world as a nail because the hammer is your only tool then something is not right. In such a scenario, should we blame the hammer or the user? IMHO, the same goes with story points. Story Points are mere tools to aid you and your team to do a very specific task (which is forecasting), however if you or your team or the management uses story points for anything else, then that’s not a problem with story points.
I am not here to make a case for or against story points. I am here to just share my experience with story points; so that if you decide to use story points you don’t end up having the same anti-patterns in your teams that we would want to avoid.
Why Story Points make sense to me:
As my mentor, friend and fellow PST Naveen Kumar Singh highlights in his article, story points are a generational gap. And if we keep that in mind, story points open a couple of possibilities for the Scrum Team.
First being a common abstract measure on which the team members can agree. In our teams we have people with varying degrees of skills and experience. These people often take different amounts of time to complete the same task; and so when they are asked to agree upon how much time it will take to complete the task there will be prolonged discussion not always leading to a consensus. People in such cases often tend to average out things, which again is not helpful.
For example: Me and my younger brother both like long drives. Now, if we have to drive from point A to point B and we have this conversation how long should it take? My brother would say 8 hours but for me it would be 12 hours. Yes, I am a slow driver. If we have to agree on how long will it take to go from point A to point B in hours we would never come to a consensus. However, what we both can agree on is the distance between point A and point B using a more abstract measure, let’s say in kilometers. So, we can agree that distance between point A and point B is 500 kms and my brother covers that distance in 8 hours while I need 12 hours to cover the same distance.
In a similar way, story points allow people to think in the perspective of an abstract measure that all can agree upon, even though people with different skills may take different amounts of time to complete the same task. A senior experienced developer can agree that a 3 pointer task is easy and may be done in half a day; while a much newer less experienced developer on team may think it might take 3 days to complete the task. But they agree that the requirement is a 3 pointer.
Second benefit I experienced with usage of story points is that they enable faster estimations. As humans we are really good at comparisons. Oh! My neighbour got a new car; that’s big I need an upgrade too 😀. I hope we don’t do that.
Anyways, the point is because we are good at comparing things; when we are estimating our work while comparing it to the work that we have previously done it becomes easier and faster. Even if we have not done similar work we can relatively compare it with work done in past and determine whether it would be more complex, uncertain and effort taking or less.
Thirdly, and this benefit comes from the practice of “planning poker”. When doing estimation when team members show different estimates for the same work item; it allows them an opportunity to discuss their ideas.
For example: if for a work item developer A says its a 3 pointer while developer B says its an 8 pointer. They both can share their perspectives why they think so. Developer A might have already worked on similar kind of work item earlier and better knows the steps to do it while Developer B might be looking at some risks which developer A might not have considered.
As they discuss their perspectives, the entire team gets better understanding of the requirement and thus builds consensus.
The anti-patterns I have observed:
- The most common anti-pattern is equating story points with hours. For ex: 1 SP = 4 hours of work. A framework has also led to this misconception.When I ask teams how they arrive at the equation, often there is no clarity and mostly fingers pointed at a particular framework.
- No baseline established. This is another common anti-pattern. Often teams do not establish a baseline to do the relative estimation and their estimates are just random numbers out of thin air.
- Renaming/relabelling story points. Our points are about “complexity” not effort; they are complexity points. Complexity is just one factor that will impact the overall effort, it is not the only one.
- Story points, the metric of productivity. This is an anti-pattern not with teams but with management. Often, people high up in hierarchy use story points planned vs delivered to call out individual developers on their productivity.
- Forgetting story points are estimates. Another management anti-pattern. Managers use story points as commitments. They even go to the length of adding it to SOWs stating, a team will deliver X number of story points every sprint. And when the team misses the mark, they reprimand the team.
Better approaches to estimation:
If forecasting is the reason for estimations and if all estimates are more or less wrong especially in complex environments then how to address it?
The answer is Flow-based metrics. The reason for estimating work is to know when it will be done. That means the customers/stakeholders need predictability. Although, story points (relative estimation) is better than the hour/man-day based estimation; they still do not bring enough predictability to knowledge work.
To make knowledge work a little more predictable, we need to focus and manage how such work gets done. We need to understand the flow of such work and what might be hampering this flow. The three basic flow based metrics that can enable more predictability in our work are
- Work in Progress
- Cycle Time
- Throughput
As defined in the book Actionable Agile Metrics by Daniel S Vacanti
Work In Progress is the number of items that we are working on at any given time
Cycle Time is how long it takes each of those items to get through our process, and
Throughput is how many of those items complete per unit of time.
Using these key flow based metrics, we can use techniques like ‘Cycle time scatter plot’ or ‘Monte Carlo simulation’ to come up with better forecasts. My partners at Agilemania also teach about these metrics and methods in their Professional Scrum with Kanban classes.
Conclusion:
Don’t blame the tool for the incompetence of the user. Story points should be used if your team has an understanding and agreement on what is their baseline for the relative estimation approach. Without that baseline teams will often end up with anti-patterns. Secondly, story point estimation is only good enough to make forecasts and have conversations around what can be done or not done. It should never be used to compare teams on their productivity or measure how a developer could be kept busy.