George Dinwiddie on Software Estimation Without Guessing (Scaling Tech Podcast Ep22)

Aug 29, 2023 | Project Management

Most of us have a love/hate relationship with software estimation. Estimation is an important skill, but it’s often misused and misunderstood, especially in unhealthy team cultures. When used properly, it can be a powerful tool for team communication and to enable good business decision making. In this episode, we speak with author George Dinwiddie about the value of estimation, and the biggest mistakes organizations make when asking their teams for an estimate.

George Dinwiddie is author of “Software Estimation Without Guessing: Effective Planning in an Imperfect World”, published by The Pragmatic Programmers. George is a software development consultant and coach who has studied both technical and human aspects of software development. George has been involved in the Agile community since 2000. Over that time, he has helped organizations ranging from a 6-person startup to a Fortune 100 company and a billion-plus dollar federal program. In addition to “Software Estimation Without Guessing,” he is also author of “Evolutionary Anatomy of Test Automation Code” and co-author of “Patterns of Agile Journeys.”

Unless you have already perfected your software estimation techniques, then this episode will be very interesting to you! You don’t have to just guess. 🙂

Listen on Spotify
Listen on Apple Podcasts

Watch the video:
Show notes with links to jump ahead are below

Show Notes from Episode 22 – George Dinwiddie on Software Estimation Without Guessing

Timestamp links will open that part of the show in YouTube in a new window

  • Introduction – The Differences between Estimation and Planning
  • 00:00 In the opening quote, George talks about the difference between an estimate and a plan: “The worst thing that can happen is that you estimate how much work it’s going to be … and someone says we’ve got this estimate and we’ll call that a plan, and we’ll expect it to follow that estimate. Well no, that’s not realistic! Plans are built on estimates, yes. But one thing that a plan has that an estimate doesn’t, is it has contingency buffers.”
  • After the opening quote, Arin and David talk about their experiences with estimation. David talks about learning to estimate with story points in agile, and then the importance of adding buffers to his estimates. Arin jokes that his primary estimation technique is “avoidance”, and compares his experiences with estimation to the 5 stages of grief, starting with denial and ending in acceptance, and feeling that an estimate must be given even if the team has low confidence in that estimate. Obviously this is not a healthy way to estimate software, and so they enjoyed this episode with George where we talked about healthier ways to estimate software.
  • George’s background
  • 05:33 Arin introduces George: “George Dinwiddie is author of “Software Estimation Without Guessing: Effective Planning in an Imperfect World”, published by The Pragmatic Programmers. George is a software development consultant and coach who has studied both technical and human aspects of software development. George has been involved in the Agile community since 2000. Over that time, he has helped organizations ranging from a 6-person startup to a Fortune 100 company and a billion-plus dollar federal program. In addition to “Software Estimation Without Guessing,” he is also author of “Evolutionary Anatomy of Test Automation Code” and co-author of “Patterns of Agile Journeys.””
  • Loving and Hating Software Estimates
  • 06:20 Arin talks about his love/hate relationship with software estimation – in his ideal world we would not estimate at all, but he acknowledges that it’s usually necessary. George agrees that he also has a love/hate relationship with software estimation – but that he sees it as necessary even if you’re working on a personal project. Unless you’re just killing time, you have to have some idea of where you’re going and what it will take to get there.
  • George notes that “I can’t think of much of any business that can get along without estimating the future in making forward looking plans and trying to be prepared for different scenarios. And so it’s writing software for a business that makes estimation so important.”
  • The Three Estimates
  • 09:31 George talks about how “Plans are built on estimates. Yes, but one thing that a plan has that an estimate doesn’t is it has contingency buffers. And estimates are your current best idea of how long something’s going to take or how much it’s going to cost or how big it is.”
  • George continues: “You can look at it a lot of different ways, but at the start of a project, that’s when you know the least about this. And so deciding that this is the one truth and everything else has to conform to that doesn’t make much sense right now. That doesn’t mean it’s not worth doing the estimate. You may do the estimate and say, ‘oh, there’s no way we can make a profit on this, forget it, let’s do something else'”.
  • George explains that in a general sense, you only need one of three estimates: 1) “There’s no way we can do this”, 2) “This will be a piece of cake”, and 3) “It’s too close to call.”
  • Adding Padding to Estimates, and a definition of “enough” Certainty
  • 12:11 Arin talks about how one of his first lessons as a manager of developers, was to double any estimate that a developer gives him. But he worried that the executives who gave those estimates would know that Arin had doubled the developer estimates and so treat it as too conservative an estimate. This made it feel like doing the estimate was pointless in the first place, and led to fatalistic expectations of working long weekends. Arin asks George to talk about this dynamic.
  • George explains that “Well, it takes a lot of conversation. This is why I wrote the book in the first place is because I saw so many people getting into verbal fights over estimation. And when people start talking about ‘no estimates’, then those seem to get even more virulent. And that’s just an awful way to live. And there’s no point in beating each other up over this topic. We need to understand each other, and that can be really hard, understanding someone who’s at a role that you’ve never been in and what are their needs. And that’s the reason I wrote the book. And that’s what the last chapter is really about, is these people aspects.”
  • George talks about how we need to break down stories into small pieces to estimate, but we still need to prioritize and put together estimates into bigger chunks of work that are useful to the business: “While estimating individual stories is a whole lot easier than estimating large, fairly nebulous chunks of work, it really isn’t what the business needs. They really don’t care how long this little tiny slice is going to take or how many of them you can fit into the next week. They’re not thinking of things at that level of granularity. They care about the delivery of all of it together.”
  • “You do need to break it down into, okay, what are the things we absolutely have to be able to do in order to have any value at all? Figure out what is that? And you need to make sure that you can feel pretty safe about getting that done within what’s considered a reasonable amount of time in whatever context you’re in. If that is iffy then you’re starting out very poorly and you need to talk about that, what are the contingencies if we can’t pull this off?”
  • David likes this definition of certainty with regards to estimates: “I like a definition of certainty that says something like this … Certainty is having enough information to act about something. There is a point where having more information doesn’t change the decision that you’re going to make.”
  • Effective Planning in an Imperfect World
  • 17:08 David talks with George about the title of the book. He feels that George’s book takes a very pragmatic and practical approach to estimation, and has a good perspective on the reality of software estimation.
  • David and George then talk about techniques like “weighted shortest job” and determining what tasks to work on. George can see value in methods like that, but warns against glorifying any method because the math can mislead you a bit about what is most important to work on. Don’t treat anything as “intrinsically pure” but just as feedback to factor into your decision.
  • George talks about using comparative estimation techniques, and jokes that Arin’s earlier estimate of doubling an initial estimate is probably not enough. He’s known managers who regularly tripled the estimates of their developers. David jokes about how he would regularly multiple an estimate by Pi (3.14). We talk about how easy it is for a “one day project” to turn into three calendar weeks due to other time commitments and unexpected things that come up in the life of a developer, and this is why padding is a helpful way to plan for contingencies.
  • Estimates that help make business decisions
  • 25:22 George talks about how do you come up with an estimate that is actually beneficial to decision making? George starts with considering what are the criteria for making that decision. Where’s the go/no-go decision or tipping point? Sometimes we’re trying to give an estimate about something that we don’t even know if it’s possible to do yet. These criteria need to be discussed. George talks about an experience he had building modem software many years ago, and how they had to do a technical spike or walking skeleton to learn the technology enough before providing an estimate.
  • It’s the Outcome that Matters
  • 30:21 Arin talks about the Ron Jeffries quote that user stories are really just a reminder of a conversation, which is the more important thing. And in the case of software estimation, the numbers and estimates don’t actually matter, the value is in the business decision that needs to be made. Psychological safety is important in a team to discuss estimates in a healthy way.
  • George talks about the difficulty executives may have in admitting ignorance on a topic: “I’ve seen a lot of cases where the executives, they don’t want to admit that there’s something they don’t know because they feel like they got to where they are by being the expert and they need to maintain that fiction to stay where they are. And that’s sort of having a culture that doesn’t have that openness in either direction obviously can harm the value of the estimates or how we use them.”
  • George talks about using models in estimation, and the risk of trusting too much in a formula built into a spreadsheet. The coefficients are often not based on real data, but assumptions. George also discusses large contract bids and how companies have to leave in profit margin space for lots of change orders.
  • Arin and George close the segment by discussing different contract models, and how to handle changes in scope and prioritization.
  • A message from our sponsor: WebRTC.ventures
  • 38:21 Building custom WebRTC video applications is hard, but your go live doesn’t have to be stressful. WebRTC.ventures is here to help you build, integrate, assess, test, and manage your live video application for web or mobile! Show notes continue below the ad
  • Visualizing Work and Balancing Speed with Quality
  • 39:08 Arin asks George about estimate visualizations like burnup charts and cumulative flow diagrams, and how they help people visualize progress. George tells a story about a client he worked with who brought him in although they had decided not to pursue agile methods specifically. Although he didn’t push agile methods on them, he started putting the team’s work on cards and visualized it on a board. In stand ups, the manager noticed his visualization of their work on a burn up chart, and asked about it. George explained that this showed the progress they were making, and that unfortunately they were adding too many new tasks and would not finish on time. In that case, the company didn’t like the message that visualization showed, and let George go. But it was a fact that they were not going to complete on time, and that project did end up being cancelled after he left and the company was sold.
  • David asks George about Chapter 4 in his book, and measuring progress. David likes it because George’s book gives the tools for situational awareness: Where am I, What was the Past, and What Does the Future Look Like? Just measuring speed may not be a good idea, because you may not care about quality as much if you only focus on speed. George discusses how teams traditionally say things like “I’m halfway done”, and then “I’m 80% done” but never want to admit they are in danger of being late, just moving more and more slowly. Measuring based on effort is hard, but if you can measure the parts that are working then that gives you some real data to go on. Taking multiple measurements and check to see if they agree with each other can be helpful.
  • Cognitive Biases and Estimation
  • 47:20 Arin asks George about cognitive biases in the software estimation, such as expert biases where we think that we have become an expert on something, and so we are no longer subject to our missed estimates of the past on that same type of work. George emphasizes that this is why for comparison based estimation, it’s very important to compare to the actual time spent previously on a task, and not try to be more optimistic that it will take less time this go around. George tells a story about a project he worked on where the boss asked him “How many more unexpected problems are you going to find?” and his jokingly serious response was “Well, all of them!”
  • Human Behavior and Software Development
  • 54:16 David asks George about Chapter 9, the final chapter in his book, which talks about human behaviors like blaming and placating and their role in how we deal with software estimation. George says that a lot of this comes from the writings of psychotherapist Virginia Satir, who defined these behavioral patterns, usually in the context of how children behave with their parents. She talked about our definition of our self, and others, and the congruence of the two. We have to consider our own needs as well as those of the person we are communicating with. George relates this to how we deal with discussing software estimation. If we don’t take into account the other person as well as our own needs, then we are going to be less successful and it degenerates into blame games or placating those in power.
  • Team Culture
  • 58:10 Arin relates the previous points about blaming and placating behaviors to signs of a bad team culture, and how this sort of culture comes from unhealthy workplaces and bad leadership. George discusses how bad estimation conversations can go in both directions, top down and bottom up, but it’s more noticeable when management is driving a bad conversation because of the power differential.
  • Conclusion
  • 01:01:08 George can be found on a variety of social media platforms, listed below, and by searching George Dinwiddie since there’s not many people with that name other than a liquor distribution company he found once in Tennessee. And make sure you pick up a copy of his book (link below), “Software Estimation Without Guessing: Effective Planning in an Imperfect World”, published by The Pragmatic Programmers!

Links from Episode 22 – George Dinwiddie on Software Estimation Without Guessing