In this article I analyse three problems I've had with story points, how I overcame these and became once more reconciled to story points as a measurement of effort. I think I can convince you too.
What are Story Points?
The concept behind story points is fairly simple. Story points are a measure of the relative complexity of a piece of work. The term relative is important here. The principle is that you assign points to each story or task based on how complex you think it is. This can be guided by looking at work you've done before that is the same or similar to this task. You can also look at unrelated tickets; Is it more or less complex than that last ticket?
I'm not going to go into detail of how you then use story points, that's a whole topic for another article.
What's so bad about this? Let's dive in deeper.
Problem 1: Repeatability
Software development is often not a repeated process. You're hired to think and apply your knowledge, experience, skills and understanding of the problem to provide a solution. You are not a factory worker that is employed to do the exact same thing day in, day out.. The process of finding the same or similar work is often impossible. There is usually something different about this task to the last time it was done. If you have the rare scenario where you're doing the same thing over and over; you don't need to do story pointing. Separately, but perhaps more importantly, you need to automate that repeatable task right now.
Problem 2: Estimation is tricky
A famous Agile evangelist researched into the effectiveness of story points for a team he was working with and found no correlation between the story points on a ticket and the time it actually took to deliver the ticket. Big 8 or 13 point tickets sometimes ended up being simple and delivered that day, whereas other 1 point tickets ended up taking weeks. His takeaway was that story pointing was an unreliable method for understanding the time required to implement a task. I think the real lesson learned here is that team really had no idea what they were undertaking and had too many unknowns or assumptions, so had no chance of being able to estimate and deliver reliably.
Problem 3: Points mean prizes
The final issue is around the external view of story points. I'm sad to say I've been in conversations like this:
"Last week the team only delivered 30 points; our velocity is 50 points, what went wrong?? We need them to work harder..."
"Team Alpha did 50 points but Team Zeta did 30 points. We need to find out why Team Zeta aren't working as hard"
This behaviour shows a complete misunderstanding of the intention of story points.
The Solutions
Problems 1 and 2 can be easily resolved through the 3-amigo process
Discover unknown work and remove assumptions
My team use a 3-amigo process to check that work is ready to be undertaken before we add it to our backlog. In this process, at least one developer, tester and product owner/manager meet to discuss the task. We have a ticket template that we refine on a semi-regular basis to make sure we're asking the right questions of the task. If anyone is unsure of an aspect of the task, we create a spike ticket and commit to a timebox suitable to understand this unknown. We work to identify our assumptions around the task and create separate tasks to remove them before this ticket is ready to be added to the backlog.
Having a rigorous task review process initially looks like it would slow you down, take you away from the delivery and make you unproductive, but in reality is acts as a shield for the team, protecting them from the unknowns, assumptions and resulting scope/estimation creep.
Story Points and Velocity are for the team only
Story points should be used as an indicative planning tool and that's it. The sprint is the team's commitment of what work they think they can get done in that time period. The points help drive that conversation and ultimately that commitment.
"Last week we did 30 points. Our previous velocity was 50 points, but now it's gone down to 40. I think we need to be a little more cautious than that this week and only commit to 35 points".
If people outside the team are trying to use that information to judge the performance or effectiveness of that team, then the team needs to work with these people to educate them on the function of story points as a planning tool, not a measure of performance.
Not meeting a commitment is more data for the team to review and understand how to improve. It's not what we want each week, but it's not a reflection of the performance of the team, just that they either were too ambitious or didn't fully understand the work required to meet the commitment. Also don't forget about unforeseen interruptions and other reasons that are outside team's control and are not indicative of the performance of the team.
The team need to use this data to reflect on the past sprints, take learnings from it and use that data to drive the forecasting and next sprint commitment.
Don't give people numbers that they have to (mis)-interpret, give them facts and show you're taking on learnings and will work to improve in the next sprint.
What's the Impact?
In the past I've been stung by the misuse of story points and it almost put me off for life. I've since moved on from that employer and found a fabulous culture in Booking.com that supports my team and lets us run the team how we want to.
I have an experimental mindset that I'm rebuilding so I suggested my team try moving to Scrum from Kanban for a recent project and I'm glad we did. We're using story points and sprints correctly, and almost every week we're hitting our sprint commitment. Our cycle time has improved, and the cycle time variance has dramatically reduced due to this and a combined approach of making each task as small as sensibly possible.
If you've been burned by story points in the past, or have a success story I'd love to hear it, so feel free to get in touch with me on Twitter. Thank you for reading and feel free to check out the other articles on my blog.
Top comments (0)