Share with me one metaphor explaining Agile estimation using story points and I will fire back with two, three, five, or more other examples. The Scrum world is replete with creative and delightful symbolic stand-ins meant to help people get good with story pointing. Buildings in a skyline, LEGO kit assembly, fruit salad, dogs and cats living together — I have heard them all.
A fellow Agilist at work turned me onto what may be my final favorite: going to the grocery store. Think of your usual go-to supermarket. In my house, we frequent a variety of grocers nearly every week, depending on what foodstuffs we need, but typically, we get most of what we eat at the same store every week.
Take a moment to picture your own grocery store. How far away is it, mileage-wise? For us, by taking the shortest route by car (we’re not crows) this store is ~4.5 mi from our house. How about yours? I had to Google to figure this out, so I don’t blame you if you do the same.
Now, how long does it take you to get there every week? Traditional estimation techniques might suggest we treat this like a math problem. If the store is six miles away and the speed limit of the roads taken averages out to 30mph, we will be there in 12 minutes. I don’t know about you, but I have very little faith in that number being trustworthy. Given enough trips, it may well be a 100% accurate prediction — but it would take a lot of trips and a lot of luck.
Think of all the ways your trip differs the more often you take it. Sometimes, your arrival time will be affected by external things. Bad weather, construction detours, other cars, is it rush hour or not, did you make that one extra-long traffic light? In countless ways, getting to the store is out of your control.
Likewise, even with every iota of the trip being the same every time you go, YOU could change the duration. Maybe you are distracted, zone out, and miss a turn. Maybe a super bad-ass song comes on the radio and you unconsciously give your car a little more gas than usual. Maybe you’re just plain tired and drive more slowly. Even with all things being equal on the outside, the same trip could take more or less time depending solely on the person behind the steering wheel: You.
So how does this relate to story pointing? Well, much like saying how long it will take you to make a drive you do dozens of times a year, estimating the complexity, risks, and effort in completing a work increment can result in a variety of very likely guesses. And several of them have a very good chance of being correct. The trick to story-pointing is to realize that you are aiming at a moving target and, even with the best data and experience, you won’t be spot-on 100% of the time. And that’s okay! Scrum estimation is about the long game, not hitting the bullseye every go.
Helping your team sit well with such ambiguity is a constant chore (we all like being right) but one that needs to be revisited all the time to keep teams moving forward. Getting tripped up on whether a task is a 3 or a 5 just wastes time that can be better spent doing the work itself.
BONUS: Relative sizing using a reference story
Even the most seasoned Scrum Team can get stymied by the ill-defined horror that is the unpointed Product Backlog. All that work and not a story point to be seen — oh my!
Now there are two ways to get this work estimated so a delivery window can be identified:
- Get the whole team together and estimate every item in the backlog one at a time.
- Relative sizing for large-scale estimation!
Once a team has taken the cognitive leap that story points are moving targets, have them estimate one item in the Backlog that feels fairly noncontroversial. Perhaps, to belabor our store metaphor, this grocer is located “right around the corner” from our house. Travel times could still vary, but the amount of extenuating circumstances are fewer, so our guesses are more likely to be correct the majority of the time.
In our hypothetical, the team estimates Getting to the Around-the-corner Store a 3. Great! Now we can quickly estimate the rest of the Backlog using relative sizing.
Think of it this way, if we “know” how long it takes us to get to the close store, will it take us more, less, or about the same amount of time to get to stores that are:
- Across town
- In another state
- In the same plaza as the reference store
- The lemonade stand the neighbor kids set up
It wastes time to story point each permutation in isolation. Rather, we quickly place the items in a spectrum around the reference store — our “true” 3-pointer. I like to do this visually, either using the brute force of sticky notes on a wall or a digital tool like Google Drawings or CardboardIt.
Once our items are all laid out in a reasonably agreeable fashion, overlay columns onto them all, with each column being headed by a Fibonacci number. While you can give the team one more chance to shift items around, I advise not doing so. Relative sizing is a great way to ballpark the effort and complexity of a large body of work for forecasting, but the team should still review each planned Sprint and call out any items that seem mispointed, either due to new info or even a hunch.
In a fraction of the time, we now have a fully pointed Backlog that can help inform how long it will take us to deliver the work in full. Yes, this number will absolutely change as the work begins and unknowns are made known or life happens and someone on your team misses a week of work due to some nasty flu, but at least that scary Product Backlog has been tamed ever so slightly.
This post originally appeared on John’s personal site on December 9, 2021.