Agile Estimating. Why Bother? IV

In this, the final part, we'll take a big spoonfull of reality: what happens when our estimates... are wrong?

= = = = = = = = = = = =

New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"

= = = = = = = = = = = =

So far, it's all been very neat. Very precise. But what happens when the estimates... are wrong?

Software Development is uncertain. (If it wasn't uncertain, then an Agile approach wouldn't be necessary.) So it's possible - indeed, it's likely - that our estimates will be wrong. This .may leave us wishing that we hadn't tried to be clever.

LINKS

-------------------
58. Agile Estimating. Why Bother? IV
# #DevelopmentThatPays

Previously... We stripped things right down. Right back to first principles. To see what happens if we take an item from the top of the product backlog, and get straight to work. Without Estimating. And to see happens if we do some estimating, and use that information to make more intelligent decisions about the build order. It's been all very clean. All very precise. But real life isn't like that. In the real world, estimates can be wrong. We've come a long way... --------- This is uncharted territory for me. I've never made a "Part 4". I almost brought things to close at the end of Part 3 ... but I thought it was important to cover just one more thing: what happens when estimates turn out to be wrong. Which is, of course, almost all the time. 1, 2, 3 ------ I want to put yourself in the place of the Product Owner. You've decided - perhaps unwisely - to build these three features in this order: 1, 2, 3 The development team sets to work. Time passes.... And at this point, the Development Team runs into a problem. It's going to take longer to build than originally estimated. This much longer. How do you - as Product Owner - feel about that Perhaps you're feeling that had this feature been correctly estimated at the outset you might have chosen a different feature to build first Hold that thought. We'll be coming back to this picture in a moment. 2, 3, 1 ------- In a parallel universe, you're also a Product Owner. And in this universe, you've decided to build the features in this order: 2, 3, 1 Make sense: features 2 and 3 together deliver more value that feature 1, and they can be delivered in the same time. The Dev Team sets to work. Time passes. The estimate for Feature 2 was spot on: it's delivered right on time. Ah now. It seems that things can go wrong in this universe too. The Dev Team reports that Feature 3 is going to be delayed - by about this much. Again, Take a moment to thing about how you feel about this Your big value item - Feature 1 - has just been pushed back. That's not ideal. Sunk Cost ---------- Two situations. Two delays. But which is better Are you familiar with the concept of Sunk Cost In economics, a sunk cost is any cost that has already been paid and cannot be recovered. Put it another way, we should be making decisions based on the present and the future ONLY. Easily done. I'll just rub out everything in the past. Does that change your feeling about either of the two cases In the first case, your highest value feature is also your smallest feature. Had you been planning work today, you'd have picked it for development in a heartbeat. So the fact that it's already in progress is amazingly good news! What about this case. Item 3 is a relatively low value feature. If you were planning now, there's no way you would have scheduled item 3 ahead of Item 1. Can you pick Feature 1 now Alas no. In all but exceptional cases, the I've-started-so-I've-finished Directive trumps the Sunk Cost Directive. You're committed to continue with the development of Feature 3. You'd be invoking the wrath of the agile gods to even THINK about putting it on hold. Epilogue -------- It's been a game of three halves. Building in order of value - without estimating - worked reasonably well. Adding in a touch of estimating gave us the ability to re-order the features to provide more value more quickly But real-world delays may have left us wishing that we'd hadn't tried to be clever with our ordering.

[justusbrake]

For me when I saw this I thought that the order could be 2, 1, 3. Get the easy win in for item 2, start getting feedback sooner, but then do 1 so that you don't run out of time and have to abandon your most important feature. I would say plan to drop the lowest value if you run out of time, and deliver ASAP is the best of both worlds.

[MikeJonesTechno]

I was all geared up for a beautiful explanation of Weighted Shortest Job First but you threw in a surprise ending to leave me in suspense again. Love this nice twist to the end of the series!

[HeshamAmin]

Estimation is a tricky subject. I still prefer doing relative estimates but take into consideration that accuracy is not guaranteed (and we shouldn't seek it too early).
I believe another benefit of estimation is that group estimation gives a great opportunity to validate the understanding of the features and making sure team members are aligned.
I agree that product owners shouldn't try to save what they've already lost (Sunk Cost). However, a couple of points should be taken into considerations:
- Psychologically, it's hard for the team to get rid of work they've "done". This should be taken into consideration with respect to the team's maturity.
- Sometimes either for the above reason or because the reasons behind the underestimation still exist, the remaining effort might still be under-estimated. In this situation, even in case No.1 the decision might be not to continue building the feature.

[arturkasza]

Great videos, on all sides (content graphics, style, voice, humour:) Kudos :) Got a technical question though. This approach to estimating and then choosing an order of developing features assumes that they can actually operate independently of each other and their value is also independent. (btw, there is no definition of value. What is value in this approach? I go with the understanding of value being the value of the benefits had by the customer minus the costs incurred, and that comes together with ROI). If you have a set of independent features you can estimate them and then go for some early value delivery. But often enough, some features are the skeleton of the application, a.k.a, Minimum Viable Product (if you've grown up reading SCRUM fairytales) or Minimum Usable SubseT (if you've been raised with DSDM fairytales). So, your vital features are the must-haves, the others are should-haves, etc (here comes MoSCoW prioritization, again a key chapter in the DSDM fairytale). So, for the whole product to make sense or just simply work, you have to start with the vital features, and not any other ones. Just like, it doesn’t make sense to fit in first floor toilets if the house doesn’t have a roof yet. And it is possible to live in a house with uncompleted first floor, let alone first-floor toilets, provided that you have all the amenities on the ground floor.

[OmyTrenav]

This is really valuable content. Thanks for posting :)

[ganguzinhosky]

just about dropping the feature - it's were Scrum comes in handy!!
if the feature takes much, much longer then estimated, it will probably not be finished until the end of the Sprint, not included in the potential release, moved back to the Product Backlog, re-estimated, re-evaluated and, what is important, treated without any "special respect" during the next Sprint Planning - it's just a regular feature in the Product Backlog to pick-up for the Sprint development
the Sunk Cost Directive is not broken by the Scrum framework

[patrickmckenna]

Hi Gary, love your videos. We were just wondering about the best way to handle dependencies. Some features will depend partially on other features. As my wise wife once said, you need to prime before you paint, not after.

[sanketss]

wooow i really mean it, the 4th video just gave me a new dimension of thinking about estimations.

[croco]

thank you for your videos and keep up the good work