The BEST part of Estimating. And how to ditch it.

Previously: I threw Estimates under the bus. Today: we’ll look at the part of Agile Estimating that YOU told me is the most valuable: What I like to call the “estimating conversation”. I’ll also introduce you to what I consider to be a BETTER conversation. And how to eliminate it. (GASP!) Are you familiar with the saying “Cutting the Gordian Knot”? Thanks to one of you I now have a great example of it. Let me explain. Around about 3 years ago, I concluded that estimates - in an Agile world - were evil. And I started to look at whether we could do without them. I’m sure I don’t need to tell you that we create estimates in an attempt to predict the future: Everything from selecting work for the next Sprint (if you’re doing Scrum) to long range forecasting. As it turns out, we don’t need estimates for either of those things. But here’s the thing: If we don’t need estimates, then we don’t need…. Estimating: the process of estimating. What I call the “estimating conversation”. And this - As many of you told me in a recent survey - that’s the most valuable part of agile estimating. So what to do? To me, my task was clear: I had to find a replacement for the estimating conversation. A knotty problem indeed! It never occurred to me that there might be a simpler solution… Until I read this in those survey responses:

Some of my teams estimate but dump all the numbers after that because the value for the team is created by the discussion, not the numbers

And there is it: a perfect example of cutting the Gordian Knot. However, I’m not entirely happy with this solution. For a couple of reasons. Firstly if we’re still estimating, then estimates are being produced. And if they are being produced, can we really guarantee they won’t leak out in to the world? And secondly, the typical agile “estimating conversation” - isn’t as good as we might think. Yes, it does have gamification on its side: Equipping each team member with a set of Story Points cards is a neat way of engaging the entire team. And when the cards are shown - and if there’s a difference of opinion - there’s the opportunity to further improve the team’s understanding of the Story at hand. I’ll go further and say that use of the Fibonacci series is a nice touch - helping us to stick to ball-park (rather than “accurate”) estimates. But the abstract nature of Story Point is a barrier to entry. Perhaps you’ve forgotten how difficult it was for you NOT to think in terms of time? (You have stopped thinking about time, haven’t you?) In any case, it adds cognitive load. And perhaps you’ve also forgotten the calibration process you had to go through to determine the exact size of a Story Point for your team. More cognitive load.

And then there’s the problem of anchoring. It’s the tendency to give too much weight to the first number put forth in a discussion and then inadequately adjust from that starting point - the starting point known as the “anchor.” Why might this be relevant? Well, even if the Story Point estimate for the Story never leaves the room, It leaves an impression on those that produced it. And it can impact how they approach development: A developer picking up high Story Point item is expecting to do a lot of work, and that might blind him or her to a quick solution or shortcut. To give you my assessment of the estimating conversation: Gamification good. Fibonnaci series good ish. Everything else… not good. I’ve kept you waiting long enough. Let me introduce you to a better conversation.. It’s called: “Story Slicing” Stay with me here. There’s a good chance that you’re already familiar with Story Slicing. You might already be doing it. But perhaps - like me! - didn’t fully appreciate its power.

On the face of it, Story Slicing is… exactly what it sounds like. You take a Story… and you figure out how to split it. Divide it. Slice it. With an important caveat: the slicing must be vertical. Meaning that each of the “slices” is “potentially releasable” - a complete story in its own right. Now slicing is one of those things that’s as much art as science. And if you’ve heard of Story Slicing before today, you’ll already be aware of the multitude of approaches/strategies/heuristics. I'll put just a selection of them on the screen. And no one loves a good heuristic more than me. But I kinda missed the wood for trees. It took me way too long to realise that Story Slicing is the better conversation that I’d been seeking. Let me show you: The Estimate conversation starts with this question: Can we understand this Story? Well enough to assign a Story Point value?

The Story Slicing conversion starts with a different question Can we split this Story? What might be counterintuitive is that you don’t need to fully understand a Story to be able to split it. Let's run through a quick example The team picks up a card and quickly identifies 4 sub-stories. Two of those stories can be split further. I’m going to highlight the Stories at the bottom of this tree: the “leaf” stories at the end of each branch. 6 in total Notice that if we were to build all of these “leaf” Stories, that would be the same as building the granddaddy Story that we started with. Okay. Next step. Chances are that not all of the leaf stories are buildable “right now”. We know from INVEST that we want stories that are independent. These two leaf stories have dependencies, so I’m going to set them aside for now. Leaving the 4 Stories that are buildable now. So far so good, and we’ve got here in very little time, and (importantly) with very little brain power. Low Cognitive load And that continues.. Chances are that not all of or 4 leaf stories are created equal. We might decide - and it would be no bad thing - to set aside 3 of them “for later”. Leaving just 1 item for now. And now - since we’re about to build this Story - we need turn our attention to understanding it in detail. Question: how much easier do you think it is to “reason about” this Story than this one compared with a big Story we started with? Not only is it a fraction of the size, but it’s also completely free of dependencies. … I’ll leave you to ponder that for a moment. But first I want to address a concern you might be having. So far I have: Taken 1 big Story Sliced it up into 6 pieces Identified dependencies Singled out one for “inspection” “What happened to the other 5 stories?” I hear you say. Two things to say about that: They may have “gone away”. Or they might at some stage “go away”. One of the (many) powers of Story Slicing is that it allows us to cherry-pick. Take a Story, split it open, pick the best bits… and move on to the next Story and do the same. cherry picking all the way.

Let’s say we did (eventually) decide to “play” all 6 Stories. Well that would mean having 6 conversations: 6 easy, quick, low cognitive low conversations. . And no, I didn’t just pull a fast one: In the case of these two, we delay the conversations until the dependencies have been satisfied.

Compare that with the original picture. The one big story that the team has to understand. A Story with a fair bit of complexity. What the team doesn’t know - but we do - is that there 6 elements hiding inside. The members of the team aren't aware of it, but they're mentally juggling those elements - and the interactions between them. That’s a lot of cognitive load. Exhausting. And time-consuming. I've talked - because it suited my purposes - as if the “estimating conversation” and the “story Slicing conversation” as being separate, distinct, never-to-be-combined. Which, of course, is ridiculous: they’re not mutually exclusive - far from it. The “estimating conversation” can - and should - lead to Stories being split And the “Story Slicing conversation” can lead to a Story Point estimate. Which brings us neatly back to INVEST. Get good at Story Slicing and you’ll find that all of your Stories are small. Which begs the question: If all of your Stories are small, why would they need to be “estimable”? Why indeed. We’ll talk more about that in the next episode.