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

There's one part of estimating that's good. Valuable, even. But we can do even better.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmen...
= = = = = = = = = = = =
Join me for a very special online training event - "How to Escape the Tyranny of Estimates and Estimating" - webinarkit.com...
-------------------
150. The BEST part of Estimating. And how to ditch it.
#AgileEstimating #NoEstimates #DevelopmentThatPays
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 a
• The BEST part of Estim...

[@Developmentthatpays]

Time to even things up and talk about the POSITIVE side of estimating. Enjoy!

[@user-rp9bq1xy4i]

Wow one of your best vidéo (nice, valuable, smart)

[@Carlos-jp6mg]

Thanks for the awesome content... I find this content valuable and informative, considering I am new to Agile and currently pursuing a Scrum Master role.

[@huggysh]

Brilliant and Engaging... Love your videos so far!

[@GaryStraughan]

Thank you! Much appreciated.

[@caresegayle1369]

Please please come back…I can watch you all day😊

[@Developmentthatpays]

You're right: it's been a while.

[@baertheblader9402]

The question remains, how do you split stories with a lot of technical prerequisites that only add value IF the dependent task gets delivered, but if you never get to that dependent task, then the pre-work is of minor value to the end user? For example, our team is working on a story to create a user interface that allows users to adjust certain business rules, but when it was first developed, a lot was made static and is not business configurable. So to accomplish this, the team needs to refactor a lot of data. This makes for a pretty large story. We could split it up so that each item that needs to be refactored is a separate story, but the end user wouldn’t notice the difference if we don’t eventually create the Settings page. Per my understanding, the user story must be valuable to the end user, so technical tasks that are merely a means to an end can’t be considered independent stories. So it seems like a large, multi-part story is inevitable, is it not?

Good question. Exactly the dilemma we find ourselves often in. I hope this question gets addressed.

[@barcleywest6720]

Rather than addressing all business rules at once and splitting it into enablers & a final user story that delivers value. Could the stories be split into smaller business rule configurables? Sorry I do not understand enough about your business to give enough context! Where I work, we would deploy & hide all smaller stories into production that offer value but do not function fully without another. Once the 3-4 stories are complete, we then release all 3-4 stories at once.

@@barcleywest6720 that's also what we do, but that's not was is suggested in the clip, it seems.

[@Chemaclass]

Story slicing! How brilliant is this idea. Kudos for this great explanation! 👏

[@Developmentthatpays]

Many thanks. You just made my day 👍

[@TheAgileLeanGardener]

Love it, great video and I agree estimates and estimating is evil. Thinking about the way you’ve described story slicing conversations has made me think about it in a way I hadn’t before, thank you.

[@nickcox7244]

I was following much of the content here, but I don't necessarily understand the concept of not letting the estimate leave the room. At a larger company, there are inevitably pieces of the product release lifecycle that are going to depend on some sort of date estimate. (Product marketing motions, other types of contributions to organization-level OKRs, for example.) It's also important to be able to set ambitious goals and achieve them, in terms of features and milestones. So my question is, how can you keep the team motivated by future goals and allow stakeholders to follow progress of features if you don't offer delivery estimates?

[@GaryStraughan]

Note that _date estimate_ - I prefer the term _forecast_ - does not depend on "estimating". It's common practice to use Story Point estimates to produce forecasts, but it's not the only way: it's been shown that a pure _count_ of stories produces a more accurate forecast. (In other words, estimating produces _less_ accurate forecasts than not estimating at all!)

[@JamesWhite1]

To understand the total number of stories in our backlogs we would still need to slice all of the stories? Or am I missing something. Love the videos 👍

[@Developmentthatpays]

For forecasting purposes? No, it's not necessary. If feels non-intuitive,, but remember that the data Vasco Duarte used for his research was subject to ZERO preconditions.

[@tomw0815]

I get the point that it would be nice to work without the pressure of estimating. But I think that none of the no-estimation advocates would hire a company for building a house that does not give an estimation or fixed price for the cost of the house. I would not pay for a software team that can't give me a rough idea of cost for the features I want.

[@Developmentthatpays]

There's an important distinction hiding here, and it comes down to language. When a builder provides an "estimate", it's a very different thing to the "estimate" that I might provide as a developer. A much closer equivalent (to the builder's "estimate") is the "forecast". Here's why: the cost/week of a software team is constant, so if you know the end date, you know the total cost. So the question becomes: "can we forecast without [agile style] estimating?" And the answer is... absolutely!

[@strangnet]

How does the builder react if you midway through the project of building a house realize that it's not a house that you need or the end user wants? How does the agile build process solve that? How often does a bathroom turn into a kitchen because of changes in requirements or user testing?

[@JeremyNathanielAkers]

Nice! So to integrate this idea in my brain I’ll need to set you up with my thinking on refinement/estimation so I can ask the question that comes up for me. I picked up a rad heuristic for the conversation as first “why?” with stakeholders then “how?” with the team. If I’m going to add slicing into that flow, where might you suggest?

[@Developmentthatpays]

You could mix it in with a Three Amigos session: - pick up a ticket - grab a "builder," a "tester" and a "sign-off-er" - talk about the ticket... with the aim of identifying the smallest thing that can be built and tested and signed-off Worth a try?

[@saishekarpeddi1239]

Its awesome but what about velocity how you want to figure it out

[@Developmentthatpays]

The next video - coming on Wednesday - talks about Velocity.

[@KyZa1111]

So if the stories are small why would they need to be estimable? Waiting for the answer for 9 months...

[@GaryStraughan]

Blimey, was that really 9 months ago! I was so shocked that I spent the last 2 hours writing the next episode. THANK YOU.

[@KyZa1111]

@@GaryStraughan :D If that's true, thank YOU! I'll need this valuable info for my company, were fully embracing Scrumban and forecasting is really important and we need at least some way to do that. Waiting for the secret to be unfolded!

[@Developmentthatpays]

@@KyZa1111 - look out for the first of TWO new videos TOMORROW (7 Dec 2022). Thanks again for kicking me into action 🚀

[@KyZa1111]

@@Developmentthatpays I can't wait! Currently struggling a bit to have multiple layers of issues in Jira (as we are Splitting the stories, there are too many branches and I can only create 3 layers: epic, story, subtask). What have you been up to all this time?

[@markusoberndorfer4634]

Great thumbnail image! I have asked myself whether you have a tattoo of a barcode now at the back of your head. ;)

[@Developmentthatpays]

I kinda want one 🤣