[NOTE: This post is about software development. You might need estimates in some other field or domain and this article is not related specifically to any other domain, and especially not the one you want to complain about.]<\/p>\n
I’d like to do a little investigation about why we need estimates.<\/p>\n
The following list contains some of the things people say when I ask “What do you use estimates* for in software development”:<\/p>\n
Let’s notice the most obvious common word in that grouping. To me, it is the word “decide”<\/strong>. Granted, the last few items don’t use the word “decide”<\/strong>, but we have to start somewhere. Besides, why would have I contrived that list and highlighted the word “decide”<\/strong> if it wasn’t fundamental to my main point? [At least I’m honest in stating that I have an agenda.\u00a0 Hint: NO ESTIMATES]<\/p>\n It is significant to me that much of why we do estimates is that we need to make decisions: To decide<\/strong> something.<\/p>\n In other words, it looks to me that what we need are decisions<\/strong>, not estimates<\/strong>. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can,\u00a0 and maybe we should explore other ways to make those same decisions. [Who are we kidding, I really think we need to find better ways to make those decisions].<\/p>\n Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here…]<\/p>\n Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along.\u00a0 That is an important point. Dwell on it.<\/p>\n Perhaps it would be advantageous to find ways to work where the quality of our decisions are not as important as our ability to learn and to adjust our course while paying as little as possible for the learning, adjusting, and “mistakes”.<\/p>\n To me, this is a “Lean approach” to making software. To me, this is the “Agile way”. Some people used to call this a “light-weight methodology” for developing software to indicate the process was “barely sufficient” rather than “cripplingly\u00a0 comprehensive and depressingly dysfunctional”. I like “light-weight”, but someone picked the name “Agile” for this idea. I like that word even better. Regardless of the name, it’s an approach where we pay attention to what is going on and constantly adjust things based on what we learn.<\/p>\n Sometimes decisions happen by default: If I forgot to bring my lunch, my options are to go hungry or eat cafeteria food today. If I forgot to bring money, then the “decision” was made for me – I go hungry. I prefer to not go hungry, but in some cases a default decision is sufficient. Make decisions on important things, resort to default decisions on less important things. Besides, I need to lose some weight anyway.<\/p>\n One little note: Of the items in the “What do you use estimates for in software development” list above, there is only one where estimates seem to make sense to me: To decide<\/strong> how much money we’ll need to staff a team for a year.\u00a0 I’ll write about that someday if anyone is interested.\u00a0 But I am confident you can figure it out yourself.\u00a0 Also, there are only a couple of items in that list that seem like important decisions to me. But what do I know?<\/p>\n As far as the “team velocity” question goes – you don’t need an estimate for that. To determine the velocity of a team simply drop them from a height of about 2000 feet and you can measure their speed just before they hit the ground.\u00a0 I’ve never tried that, but I’ve worked some places where it felt like that.<\/p>\n So the title of this post was “Why do we need estimates?”. The answer is, we need them only if we can’t find a better way to make decisions.<\/p>\n There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.<\/p>\n Perhaps you are now saying: So what? I don’t know of a better way, so I am going to use estimates. Besides, what’s so bad about estimates?\u00a0 Well… I’ve written a little about that (although I’ve really just started – there is a LOT of potentially bad stuff about estimates we should all be aware of), and about a few alternatives to using estimates. Over time, I’ll keep adding more information, and share more about how to make decisions without estimates. In the mean-time, I know that many others are also finding ways to make great decisions without estimates, and some of them are writing about it as well.\u00a0 Google that.\u00a0 You can probably figure this stuff out better on your own, anyway.<\/p>\n NOTES:<\/p>\n * For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)\/function(s)\/capability(ies)\/bug fix(es) being requested.<\/p>\n Disclaimer: There are many situations where estimates can be meaningful and useful. \u00a0This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.<\/p>\n","protected":false},"excerpt":{"rendered":" [NOTE: This post is about software development. You might need estimates in some other field or domain and this article is not related specifically to any other domain, and especially not the one you want to complain about.] I’d like to do a little investigation about why we need estimates. The following list contains some […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,22,24],"tags":[],"class_list":["post-638","post","type-post","status-publish","format-standard","hentry","category-estimating","category-no-estimating","category-noestimates"],"_links":{"self":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/638","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/comments?post=638"}],"version-history":[{"count":49,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/638\/revisions"}],"predecessor-version":[{"id":1032,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/638\/revisions\/1032"}],"wp:attachment":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/media?parent=638"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/categories?post=638"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/tags?post=638"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}So to restate: We don’t need estimates, we need to make decisions.<\/h4>\n
One other thing about decisions<\/h4>\n
One other other thing about decisions<\/h4>\n
One other other other thing<\/h4>\n
In Conclusion…<\/em> We need to make decisions, we don’t need estimates.\u00a0 Did I say that already?<\/h4>\n
Some other posts I’ve written on the topic of estimating:<\/h4>\n
\n