When working with agile teams, the use of story points is often the touchiest element to adopt for them. I’ve seen many creative ways of using them, often as the result of reporting demands from management and team members seeing no clear advantages in the utilization of relative estimation compared to traditional well understood time in hours and days.
To help, this article looks at how story points are used across organizations, with advice on their best application in respect of two common hindrances in agile teams.
How story points are misused
A common mistake is to use story points as a reporting tool for management – for them to feel safe about progress and be able to compare the teams. When working within organizations where the teams or team leaders are used to being performance measured, I’ve seen where the manager insisted that a simple feature was to be given 1,000 points and then moving upwards with an extra 1,000 for a bit more complex feature and so on. The only reason for this was that the manager wanted to have the “best team” producing the highest number of story points when management compared the teams.
Another way of using them is to decide that one story point is one day and, therefore, that half a day is 0.5. But then you’ll never improve the velocity of the team because the number of story points you can produce per iteration will always equal the number of team members and their presence.
So, what’s really the intention of story points, and why are they a powerful tool that should be adopted by agile teams?
The issues with traditional estimation
When working in an agile manner, every team member matters on the same level – and titles are not important. Of course, there will usually be skills on different levels but that’s considered when working with story points as are the complexity and potential risks. They embrace all the necessary effort in producing a user story.
If you stick to measuring user stories in actual hours, then it will often be a one-person estimation because you will look at the most experienced and highest skilled team member to get the most accurate estimation. But this is vulnerable since you then make the estimated person dependent.
A specialist who estimates a task isn’t always the one who implements it and senior and junior developers need different amounts of time to complete the same task. The only way to avoid this issue is to get the developer who estimated a specific user story to also implement that user story.
How story points help
Story points eliminate this issue because they are a universal measurement across the whole team. The estimate doesn’t depend on who’s implementing the story. All team members, with different skill levels, can discuss it together and come to a single conclusion. The whole team can get a clear understanding of the story’s size and complexity. It also makes it easier to re-plan product release deadlines without re-estimating all tasks if members of the team are changed.
Another key to the power of story point estimation is to look at the velocity. Velocity is a powerful capacity planning method that demonstrates how much backlog effort a team can successfully commit to their Product Owner in one sprint. The goal of a team is to raise its velocity. But you should also be careful not to fall into the trap of raising the number of needed story points for equal user stories in future sprints just to obtain a higher velocity, nor should you compromise quality to achieve a higher velocity. This happens as soon as you start comparing the velocity across teams. Velocity is measured per team and it, and story points, is the team’s planning tool to deliver ever more accurate estimations and certainty in the commitment to the deliverables in the upcoming iteration.
What’s really the intention of story points, and why are they a powerful tool that should be adopted by #agile teams? This article explores. Click To TweetMaking story points useful for the team
Despite the advantages of relative estimation a lot of teams have the impression that it has no value for them – that story points are just a fancy but useless concept and yet another way of performance measurement. This perception is usually derived from mixed signals in the organization. Are story points a management measuring tool or a tool intended to support team development?
So, how can you as a Scrum Master control or eliminate traditional management behaviors and support your team in adapting to story points?
First off, is sitting down and having a serious talk with management because they – in my experience – are the level in the organization introducing the most anti-patterns when working in an agile manner. Often management secure training for the new agile roles but fail themselves to obtain the necessary knowledge of what it means to work in these new ways. They often keep insisting on using the traditional ways of measuring performance and progress and do not empower teams to work in a self-organized way. The outcome of this is decisive as to whether story points use will be a driver for better accuracy and productivity in the team or just traditional estimation and reporting with extra steps.
When you have had the conversation with management then it’s time to get into a good dialogue with your team. Explain in depth the value of story points but also point out the pitfalls. Then agree on a couple of “test iterations” for them to get an understanding of why the number per story really doesn’t matter and why the user stories put in relation to each other and the team’s velocity in total gives the value as a planning and commitment tool for them. In this test period, you as a Scrum Master must avoid any traditional reporting to management and refuse to compare teams. Working with story points is the opportunity to break from traditional measurement and management thinking and therefore a hard nut to crack. But if you crack it properly it will be of great value in shaping the culture in the agile team.
There will always be pressure from management to keep costs as low as possible, to deliver more and faster, and the possibility that they will “short-cut” the agreements within a team. But if management doesn’t honor the values and principles of the ways of working agile, and keeps measuring in the traditional ways, then why choose it in the first place? It’s a difficult conversation but a necessary one if you are to succeed in being the Scrum Master of a self-organized agile team.
How can you as a Scrum Master control or eliminate traditional management behaviors and support your team in adapting to story points? Take a look here. #agile Click To TweetUnfortunately, I’ve seen many organizations where they interpret the role of Scrum Master – who is a servant leader – as being the secretary of the team who is expected to do “what they are told.” This often leads to situations where the Scrum Master feels pressured – either by management or a team that’s unwilling to adapt to the new ways of working – to introduce anti-patterns. And even though it should not happen, it can – in the short term – be a way to secure a step-by-step commitment from both team and management. But be aware that if you don’t have your own agile strategy for how to end up “fully agile,” then you potentially end up with multiple ways of “working agile” in an organization – impairing cooperation both in regards to work on products and improving the ways of working.
The bottom line is that a lot of organizations struggle with using relative estimation and it is – in my experience – the most common anti-pattern when working in an agile way.
A way to secure a team’s commitment to using story points, when estimating the work of the backlog, is to start with management and have the hard conversation on how to measure progress and performance in an agile team. The goal is to make sure, that story points are only used for their intended purpose: a tool for a team to deliver more accurate estimations with more certainty in their commitment.
The views reflected in this article are the views of the author and do not necessarily reflect the views of the global EY organization or its member companies.
