Story Point Estimation in Scrum: Some thoughts, advice, and a bit of ‘how to’.

I’ve been struggling with this blog post for a while. Part of the struggle was figuring out what I wanted to say. The rest of the struggle was trying to figure out how to create a convincing reason to estimate requirements using story points instead of hours. At the moment, I’m on a plane returning from teaching a Professional Scrum Foundations class in Madison, Wisconsin. As usual, when we got to the point in the class where we teach story point estimation, people got confused. It’s the moment where I can see my students brains itch, lock up, and melt. “Why would you ever want to do anything that doesn’t result in hours?

I’ve been reflecting on that inevitable confusion and my own problems trying to succinctly explain the “why” of story point estimation and it dawned on me that it is simply just another one of those Scrum-related topics where you just kind of have to discover the “truth” for yourself. So much of Scrum coaching is just trying to gently guide your coachees toward an answer without actually giving the answer.

In short, story point estimation works. And as to why you want to estimate using story points rather than using hours, hour-based requirement estimation doesn’t work. (There. Done. Writer’s block log jam on this blog post is now cleared.)  The reason that you’re going to stop trying to estimate requirements in hours is because it just plain does not work. But it’s not like story point-based software estimation is all that glorious either. To paraphrase Winston Churchill, “[story points] are the worst form of [software estimation], except for all the others.”

Here is the story point process and some thoughts on getting started:

• Each Product Backlog Item (PBI) gets a value. For each PBI (aka feature, user story, requirement), you’re going to assign it a story point value.
• Fibonacci Buckets. The values you’ll use are usually based on a modified version of the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 40, 80, infinity. You’re using Fibonacci because there is numerical space between the numbers. These values create ‘buckets’ that you can toss PBIs into.
• Something from nothing. Your goal is to establish a way to do ‘relative sizing’. Meaning, you and your team are going to use story points to represent the relative sizes/effort between your PBIs. “Is PBI A bigger or smaller than PBI B? Is it bigger or smaller than PBI C?”
• Estimates are team-based. When you come up with a story point estimate, you are going to estimate all the work that’s required to make that PBI ‘done’. This will include everything from software development to testing to user acceptance to deployment. Everything. Since you’re estimating all of these activities together, you are required to estimate how long it’ll take the whole team to get this done rather than how long it will take individuals to get this done.
• Mindset.  This might seem weird at first but there are major benefits. 1) you get into a mindset where the whole team succeeds in delivering Done functionality rather than a bunch of individual, heroic (or not so heroic) efforts. 2) You’ll generally try to think less about certain individuals doing the work and instead think more some kind of amalgam of the resources available.
• More than one path.  The fact that you’re thinking about some kind of abstraction of resources rather than specific people doing specific tasks, you actually get better estimates that better enable self-organization on your teams. Think about how schedules shift and move as people get pushed and pulled in different directions and as people’s schedules change. Yah…you might think that you’d write the code for PBI A but then you get pulled off onto something with PBI B that makes you 100% busy and now a more junior member of your team is going to write that code and your original estimate for hours is out the window. If you estimate as a team, the ‘noise’ of shifting resources tends to get averaged out.
• Establish context. When you’re first getting going with story points, you need to establish some context. The easiest way to establish context is to “estimate” stuff that you’re already delivered. You know how hard it was because you already did it. There’s no longer any fuzziness in the requirements because you did it. It’s shipped. It’s delivered. It’s understood.
• Establish your ‘medium’. When you’re first starting out with story point estimation, you’ll take a PBI that your team has already delivered and thinks/agrees was roughly a medium-level of complexity. You’re going to assign that a 5, meaning that that PBI is worth 5 story points.
• Establish the space around ‘medium’. Take some other PBIs that you’ve already delivered and start asking yourself “is this bigger or smaller than the PBI we called ‘medium’?” Pretty quickly you’ll start to have some kind of a feel for what these story point values actually mean in terms of relative complexity.
• Estimate undone work. Now that you’ve established some context, you can start estimating some work that you haven’t done yet. When you start trying to estimate these new PBIs, compare their complexity to the PBIs that you’ve already completed and estimated. Assign these new PBIs to their story point Fibonacci buckets.
• Why use Fibonacci buckets? Because it helps you to not get obsessed with getting your estimates exactly right. You’re not going to obsess about whether something gets the story point value of 13 or 14. You’ll ask yourself does this feel more like a 13 or more like a 21.

Now, that I’ve explained a bit about story points, I’m going to dump on hours-based requirements estimation a little bit more. Let me clarify — when I coach Scrum teams, we only do story point estimation for the Product Backlog Items (PBIs). The actual tasks in the Sprint Backlog are estimated in hours. So, there’s definitely still a place for hours in Scrum but you’re going to use that wisely for things where hours make more sense. To quote my colleague, Erik Weber from Centare, “hours-based estimation works best on things that are small.” When things start getting big, teams start getting profoundly bad at estimating.  Estimate your PBIs using story points and use hours for your sprint backlog’s tasks.

Everyone thinks in terms of time — hours, days, weeks, months, and years — but software estimation is more complex than that. Trying to put hours on a feature (aka. PBI, user story, or requirement) puts you into a mental space that leads you in the weird directions and often wastes a lot of time. How often have you started working on something that you thought would take 8 hours and suddenly you have a new understanding of the complexity of the problem and takes 40 hours? Or how about you’re working on a feature with a couple of colleagues and you don’t all work at the same pace and don’t all have the same level of expertise on all the required activities? Or maybe you spend 30 minutes coming up with an estimate. Your boss hears that estimate and says “spend a couple more day on that estimate and make it bulletproof”. You spend a couple more days on that revised estimate. The new estimate is not significantly different than the ‘quickie’ version. At the end of your project, you find out that both estimates were wrong.

Whatever you end up doing, you’ll do an hours-based estimate on a bunch of PBIs but you forget to include some non-optional activity like QA or deployment and, in the end, your estimate is wildly wrong.  It’s always something.  Whether it’s something you missed, something you got wrong, or just some kind of ‘fire drill’ while you’re developing – it just never works out.

These things happen all the time. In short, estimating in terms of hours can be incredibly wasteful and you almost never get close to the real values. Also, if you estimate your PBIs in terms of hours, it’s entirely possible that the hours spent on the Tasks for that PBI does not actually end up being the same as the original hours-based time estimate on the PBI. It’s always really weird when a PBI that’s “40 hours” ends up taking “60 hours” or “20 hours”. The number of hours a PBI takes is very flexible and variable.

And now, drawing this minimally coherent blog post to a close, I’ll reiterate the main reason for “why story points” is that estimating in hours simply doesn’t work. You need something else. Story point estimation isn’t perfect but it’s better than nothing and, most importantly, it doesn’t even bother trying to get accurate hours-based estimates for the PBI. There’s a hubris to hours-based estimation on PBIs. Story points have a built-in flexibility and humility that says “we forecast that this is how much effort it will take but we’re often wrong so please don’t take those hours as a guarantee.”

-Ben

— Looking for help getting better at software estimation?  Want to start using story points with your Scrum teams?  Need some training on Scrum?  We can help.  Drop us a line at info@benday.com.