The Real Reason We Estimate

Over the past few months, various blog posts have popped up talking about estimation, how estimation is unnecessary, how estimation is waste… and that maybe we should stop estimating entirely and just get down to the business of writing software. If our estimates are always wrong, and most of the time they are, why should we even attempt estimating in the first place?

Agilists eschew absolute estimates in favor of relative estimates, and absolute values to estimates made in more abstract units like story points. Story points are measured in non-linear sequences like Fibonacci to further abstract their value from any notion of absolute time. As a result, agile estimates are only relevant in the context of a stable team with a known measured velocity.

Many teams aren’t any better with agile estimating than they are with traditional estimating and I think this is what leads many folks to reject the notion of estimating entirely. If agile estimating doesn’t work any better than traditional, why bother estimating at all? Personally, I’m a big fan of estimating and teach it to all the teams I work with. Estimating can work… but only if you understand why you are doing it.

You see… estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem. If you can get to the bottom of your shared understanding problem, you will fix your estimation problem.

Shared understanding problems can result from any number of organizational dysfunction’s. Some of the most common are on the product side… insufficient business involvement, insufficient understanding of the business problem, and insufficient requirements decomposition tend to result in sprint planning meetings that are too long and not detailed enough.

When there there is too much of the wrong kind of discovery going on during sprint planning… teams will get tired and frustrated and end up committing to the sprint deliverables without sufficient understanding of what they are going to build or how they are going to build it. They’ve estimated and discussed, but they’ve never gone deep into the details. This always results in too much discovery going on during the sprint, too much unanticipated work, and too many missed deliverables.

The other big shared understanding problem comes from technical debt… poor architecture, quality problems, or even just teams that are unfamiliar with the code base, all result in making commitments without a clear understanding of what work actually needs to be done. When you couple a general lack of understanding about the requirements, with a general lack of understanding about the code, it’s no wonder people are frustrated with estimating.

Giving up estimating is basically giving up being able to give the business any idea of what they are going to get or when they are going to get it… even at a high level. My take is that we can’t give up estimating, we need to get better at estimating, but that means that we need to get better at creating shared understanding. It’s my opinion that creating shared understanding is the main reason we estimate.

It’s not so much the number that matters… it’s the shared understanding matters. If we are estimating without creating shared understanding, we are missing out on the value, and the estimates will always be poor. If our estimation process increases the level of shared understanding, our estimates won’t necessarily be right, but they should be consistent… and consistency is all we need especially for establishing a stable velocity.

So… if we want better estimates, or at least more consistent estimates… our goal isn’t better estimating, it’s more shared understanding. The question now becomes… how do we create more shared understanding?

LeadingAgile CEO and Founder, Mike Cottmeyer is passionate about solving the challenges associated with agile in larger, more complex enterprises. To that end, he and his team are dedicated to providing large-scale agile transformation services to help pragmatically, incrementally, and safely introduce Agile methods.

Leave a comment

46 comments on “The Real Reason We Estimate”

Yes, this is spot on, great post. I think the main challenge with estimating is finding the balance between spending enough time on a story to get a reasonable accurate result and not spending too much where people start thrashing out the details. Going to deep while estimating can become “big design up front” and you loose the iterative nature of agile. It also gets really boring for the team. I prefer not to go down to task level for this reason.

Thanks much, this deserves a lengthier reply, so maybe I’ll do a post on it… but I actually do teach task breakdown, at least at first. New teams have little understanding of how each other think about work. Breaking down tasks helps them learn each other, and creates a way of tracking progress with unevenly sized backlog items. As shared understanding of the product, and each other, goes up… and we start breaking down features into smaller, more similarly sized stories, I relax the requirement to break down tasks. It all depends on how much shared understanding we have… the more shared understanding, the less specificity. The less shared understanding, the more specificity.

I am one of the guilty parties in that I am a vocal opponent of the current status quo approach to Agile estimation and planning. I mostly agree with everything you said. However, while I believe we agree about the goal, I don’t feel that the approach most teams use is the best way to get to that goal.

An anecdote: I had a team that was spending several hours each sprint coming up with detailed estimates, but they weren’t getting the things done that they expected to. I pointed out to them that the entire planning meeting was being spent on the numbers but that they weren’t achieving the shared understanding you are talking about. They nodded and continued doing what they were doing.

I began to think about a better way to illustrate the problem to them, and I decided to introduce a Kanban board. They really liked the Kanban board, and after just one sprint with it they suggested on their own that things moved when they moved and there was no need for estimates in hours (which they themselves knew were horribly inaccurate anyway.)

At the next planning meeting the team observed that since no task estimates were needed they could have a much shorter meeting. I suggested that instead we start talking about what the acceptance criteria for the stories were and how we would determine we had achieved them. The meeting was shorter, more pleasant for everyone, and everyone left with a shared sense of what they would be doing.

Since then I attempt to do the same thing with most teams. My approach can be summed up as:

1) No tasks
2) “Goldilocks Sizing” for stories (Is it too big to accomplish in the sprint? Is it too small to be a story on its own? Or is it just about the right size to finish comfortably inside the sprint.) No numbers.
3) Discuss acceptance criteria as a team and identify what it would take to know it was done. Nothing is “captured” per se (e.g. in a tool) but individuals may take notes if they find it helpful. The goal, as you mentioned, is shared understanding and commitment.

Communicating expectations to the business is a separate but important discussion. That was never the goal of the planning meeting anyway. I have always viewed using story point estimates – which were devised to help the team steer its own efforts – as a way to communicate information to the business as a Scrum antipattern. We never did this in XP in my experience. It makes a lot more rational sense to find out what question the business really wants answered and find a way to answer that question directly.

Adam… my general bent is that just because a team is estimating poorly and not achieving the desired outcome, that is not a reason to stop estimating. I would rather coach them to do the things they are doing more effectively. IMO, there is noting inherently wasteful in estimating… but I’d agree that there are people estimating in ways that are wasteful. There are many folks going through the motions without a full appreciation for what they are actually trying to accomplish.

The other part of this is about knowing when you are going to be done. The whole thing about delivering as much value as possible for the time and money you have available is a non-starter for me. I spent three sprints with a team building a product backlog, establishing a stable velocity, AND creating the core of a working product that was potentially shippable. We realized that the remaining backlog was 5 times what the business wanted to spend.

They decided to stop the project after another two sprints (5 total) and save the remaining 50% of the project budget. They were generally unhappy with the outcome (didn’t get everything they wanted), but would have been far LESS happier had we consumed the entire project budget without delivering everything they wanted. Creating as estimated prioritized backlog allowed us to do this. Had we not estimated, all we would have had no way to measure this.

Like most things… what you did was sound. Sounds like you are doing the simplest thing that could work for that team. Most of the teams I work with will evolve toward something similar after 3-4 sprints. Estimating, especially early on, helps the team get the shared understanding we both agree is essential. At the point of shared understanding, stories are smaller, the team is better at working together, and they know what they are building. Sure… stop estimating the details. I still want a sized backlog and velocity to communicate status.

If you don’t need this, you work with a totally different class of customer than I do… most likely in a totally different problem domain. Having a general idea of what you are going to get and when you are going to get it IMO is essential.

Mike, if your goal in estimating is building shared understanding, then I think there are better ways to do it. I find that developing acceptance examples with “The Three Amigos” (business, programmer, tester, & possibly others) works better to give that understanding, and it gives a leg up on testing, also.

Small scale estimating in iterative Agile projects should just be used to decide how much to tackle in the coming iteration. If you’ve come up with concrete examples that illustrate the important behavior, then this estimating should be pretty easy by looking mostly at the number of examples. I recommend turning it around the other way, and splitting stories to contain a few examples so they can be effectively treated as the same size. Then you can just count them and choose the number that you completed the previous iteration.

For large scale estimating “to give the business any idea of what they are going to get or when they are going to get it” I recommend working in bigger chunks. If things are tight, then the chunks can be trimmed during implementation by dropping some of those small-scale concrete examples and the functionality they describe. There’s a certain amount of error in forecasting, anyway. That’s the nature of estimates. You can generally get close enough using the approach I describe in http://blog.gdinwiddie.com/2010/04/22/projecting-into-the-future/ And if it’s too close to call, you really should have some risk mitigation plans in place.

Estimating is A WAY to gain shared understanding, but it’s certainly not the only one. The Three Amigos approach works on the shared understanding directly, and lets the estimates fall out of that.

First, I might suggest that if you are spending time thoroughly breaking down stories to the point they are small and uniformly sized, that is just another way of estimating. That said, I don’t disagree with anything you’ve said here. I’m a big believer that we should do the simplest thing that will work for any team, for the business problem they are trying to solve, and the constraints they are under.

I don’t think it is good advice to make a blanket statement that estimating is waste…. I don’t think we should give blanket advice that you should always estimate. My point here, is that if you are going to estimate, the number is valuable (for projecting forward) but it’s not the primary purpose… it’s more about helping the team come to that shared understanding.

Maybe a point of clarification, estimating to me isn’t a precision activity. I use story points, fibonacci, etc. I just find that the process of estimating, the conversation it generates, and the shared understanding it leads to is valuable. I do start most teams with task breakdown and hour estimates, I will sometimes use planning poker at the task level. Depends on where the team is when i get them.

So, lot’s of variables here… but the teams I work with get a ton of value starting this way. As their level of understanding goes up, I want them to lean out their process as much as possible. Thanks again for taking the time to leave a comment. I appreciate it.

As George already mentioned the three amigos practice is really helpful in order to gain a mutual understanding of the problem. I prefer to combine that with Acceptance Test-Driven Development so that we can include the customer. There is really no need to employ estimation in order to understand a problem. What we need to know should be expressed in examples (e.g. Cucumber scenarios) co-authored by the customer and accepted by the customer. Then the team will know what is expected and when they are done.

Estimation is really about what the effort for something is. A better understanding of the problems presented may come out of an estimation session, but in my opinion there are other practices (ATDD, 3 Amigos) that are directly aimed at getting to the point. None of these practices involves any form of time consuming meeting but direct collaboration to solve the problem at hand.

My opinion is that estimation should not be done by the team. Why bother them with the fabrication of an elaborate forecast for the future? We know how much we achieved the last few iterations so we know how much we can promise for the next iteration. If our stories are small and have well understood acceptance criteria, then “estimation” is really a 5 minute thing for someone like an iteration manager. It’s not that programmers, testers and analyst should spend their time on that.

That said I’d rather teach a team how to do mutual problem solving, 3 amigos, Acceptance Test-Driven Development than discuss what they believe they will have to do during the upcoming iteration. They will forget most of it anyway and it is all based on assumptions. Instead of spending time estimating and discussing things, I’d rather have them enter a conversation with their customer on the acceptance criteria based on Cucumber scenarios prepared by the analysts. That brings us closer to delivering something of value and we can much easier show progress based on working software actually delivered.

Some organizations still require estimates but providing them shouldn’t be the team’s job anymore.

Because if you read that book, Mike… … … I guess there’s a point in there somewhere.

Agree with all you’ve said here. What I liked most is about the shared understanding. Most of that comes down to what? Relationships. … Then all the aesthetics of trust… We need not forget the relationship building going on throughout all these exercises.

I think to call it estimating – if the real goal is shared understanding – is a bit problematic. How do you know when you are done – when you have a number – or a date? The necessary understanding and breakdown of the work are definitely needed. The idea that we should put a fine-grained number or date on it are probably dangerous. I would agree that ATDD in a team collaborative approach is the better path. The accuracy of estimates is hideous and invites working to the estimate… the same is true of dates… and sadly, the strong tendency is to feel no pressure in finishing early – dooming schedules to slide. An estimate is just a bad bet – as is a date; they suggest normalized workers, insulated teams & work environments, minimal change, professional estimators, and solid historical data. Good luck wiht that. Shared understanding on vetted requirements though – the holy grail. Surely we don’t need to pretend estimate to get these?

I agree with a lot of the aims of this article, but even more with what Adam Sroka wrote. However, I am not really a Scrum guy, I much prefer the Kanban/Scrumban approach. Basically I try to be Lean about all my processes and my thoughts usually run a long the lines of:
“will this activity help the team to get user value to the users faster?” and “how will we use the outcome of this activity?”
In the case of estimating I don’t think it will help the team get value to the user and I am unsure if the outcome really affects anything. However, I do agree we need some activity to create a shared understanding so if estimating works best for your team then great!
But, there is some evidence (ref missing here, it’s Monday morning and my Google skills haven’t booted yet) that I have read that teams tend to fulfill the upper end of estimations making them slower than they would otherwise need to be. One has to ask oneself, will the outcome of estimation change anything? If not then it is a wasteful activity.
So in summary I am with Adam on the Goldilocks sizing strategy, I have used it extensively in the past and found it to work very well.

We get a real benefit having the whole team together discussing stories (as long as we keep it short), there are many cases where somebody you wouldn’t expect chirps up with “but we’ll need to change…” that everybody else has missed. Although just having the “3 Amigos” working on acceptance criteria sounds like something we should try (Working with 7 devs at once can be intimidating for BO & QA) I worry that not including the whole team could damage not only the shared understanding but also the shared collaboration and responsibility for a story.

Deeply insightful (as always). But I’m rather with George on this one.

If it’s about building shared understanding (and that rings true), then calling it “estimating” is a bit misleading. And let’s not forget the higher-ups’ perspective (and other stakeholders external to the team, too). Any halfway-decent job of “analysis” should build a shared understanding of not only the job to be done, but also the needs of the various stakeholders in the context of time-lines, schedules, coordination-points, etc. “Estimation” is often the knee-jerk solution to those (generally unaddressed or poorly-understood) kinds of requirements. Until a team makes these stakeholders and their needs visible, it’s difficult to think that they could find a good solution for them.

Okay guys… everyone is making great points, and in general I agree with most everything you guys are saying. Here is my question(s) though… are you guys spending someone else’s money to build software? If so, is it reasonable that your customer should have some idea of what they are getting for their money? I’m not suggesting they know *exactly”, just some idea.

It seems to me you guys are really suggesting that our customers show up with a big pile of money and allow us to spend it two weeks at a time (or feature by feature) without ever having any understanding of the level of effort involved or where we might be when the money runs out? I challenge you to find any area in your life where you’d agree to that kind of a deal.

I get that many teams estimate poorly. I get that even under the best conditions, estimates can be wrong. I get that no matter what we do, some executive will misuse our estimates. I get that estimating often leads to making commitments that are not good for the team or for the business. All I am suggesting that this is simply poor estimating and bad management behavior.

My take is that we should estimate well, as a team, in collaboration with the business… to get a shared understanding of the problem and of the potential solutions. We should use the numbers to track our own progress, to make trade-offs, to manage scope, to fine tune the requirements and the implementation… and manage the expectations of the business as we go.

I’ll reiterate though that any team should do the simplest, easiest, fastest thing they can do to make their customers happy. If their customers don’t care when they will be done, and are happy spending money in the way that you guys seems to be suggesting, than you guys should do exactly what you are suggesting.

If you have customers that need some idea of what they should expect for their money, and they need an up front estimate to get funding, and you are going to have to do an estimate to win the job, you should estimate in a way that creates shared understanding rather than going through the motions and putting a wild ass guess on some user story.

IMO… if a team doesn’t have a good understanding of their backlog (both in terms of product need, solutions space, and size) AND have a stable velocity from which to measure progress against that backlog… you do not have any kind of credible plan to indicate you are going to be successful.

As a side note… and then I’ll stop rambling for now… I told this one SVP of Product Development one afternoon to stop asking the team for estimates and dates. I told her that all they are going to do is lie to you. They won’t lie on purpose… it’s just that they don’t know. If you pressure them for a dates, they cave and give them to you, you’ll make commitments to your customers, and the teams won’t deliver.

Once your product team and the engineering team work together to create that shared understanding of the backlog (in terms of product need, solution, and size) AND they have a measured velocity against that backlog… then you can start talking dates and such. Until then, you have no idea how you are progressing.

(BTW – I’d say much of the same to those that want to use Kanban language. We can drop iterations and velocity and replace it with operations reviews and cycle time. I’m also okay if you want to stop estimating and focus more on decomposition and start measuring standard deviation. These ideas are all from the same root, but the principles I’m talking about don’t change… until you have data about your progress… hard numbers… you are winging it…)

I actually love this discussion especially as one who believes “estimates” have their specific use case. Before an estimate is done, we need to ask ourselves, why are we really doing one?

Mike, to your pointed question as to whether we’d agree to this kind of deal, I think the problem I see is that we are not honest about the nature of our work. I for one, believe that we are in the process of conducting experiments and trying to create recipes that address problems. Creating estimates for creating recipes (not executing them) is something I find fascinating and IMHO, inherently very flawed. The other dimension to this is that we can’t predict when/how information will arrive into the development cycle.

I agree with your notion that what our customers are really investing in, is not new features, but experimentation and learning. When I’m in that mode, we have to really constrain the investment rather than estimate it. The problem is that most customers don’t understand this dynamic. They think they are getting features, when in fact they may not.

Going back to my question. I may be willing to pay my mechanic $100 to figure out what’s wrong with my car, but at some point I need an estimate that we can both live with. On occasion I might be tolerant if the estimate was wrong, it wasn’t a transmission problem, it was the engine. But if my mechanic is always wrong, or continuously charges me for discovery, and I never get my car back, likely I will go find a better mechanic.

It strikes me that most of these discussions assume a certain style of development such as a customer ordering a project to be done with some up front financing. It is my conviction that projects are suboptimal in most cases and if we stop thinking in projects it frees our minds to come up with new angles to approach the software development problem from.

Context is everything.

If I was paying others to develop software for me I would be interested in having something of value early and make the software “self funding” as soon as possible. As soon as I make more money from the software than I put in the rest is optimization (provided that I have the software written to make money).

If we know that we are getting enough benefit out of the software to motivate the team then the question is more “how do we do what we do even better” rather than “when will we be done”.

If I was paying for software I would be more interested to see that things are happening continuously, that the right things are happening continuously and that what is done reaches the intended audience at the earliest possible moment. Estimates would be of less interest to me. In fact I would not be that interested in commitment to a sprint-scope or any of that stuff. I would be interested in getting some working software that I can benefit from now. And I would want to have the feeling every day that the progress is reasonable, and I would do what ever I can to improve my sense of what reasonable is.

It also strikes me that so many arguments about pretty much anything are in the style “We call it X but we really want Y”. If we want Y we should call it Y:ing not X:ing. And if we know that we are Y:ing and not X:ing we can free our minds to drop X:ing for Z:ing if it improves our Y:ing.

As others pointed out, estimating is not the only way to build knowledge and it is probably not even the best way.

In fact, it is my conviction that while explicit estimation is not worse then everything else; there is always a better way to do things that does not require explicit estimation. I can’t prove this and I don’t always know which way is better but I still believe this is the case and I understand that others believe the opposite with about as much proof…

First of all, thanks for the comment… I appreciate the time you took to write it. It’s funny… I write a post about why we really estimate, and I agree with most that estimation isn’t always necessary. I also agree that it is broken in many contexts. In my context… complex systems of systems, where outcomes have to be coordinated across geographies and across multiple teams… where things have to be in sync, I can’t imagine not estimating.

The domains I work in are less emergent, and more convergent. We are trying to hit a specific target 3-6 months out, or get as close to it as we can, or pull the plug early and invest in something else. If I were building a product from scratch in an unproven market, where I was putting my own money *at risk*… I would do the same thing. If I were incrementing a product, where the deal was already sold, and I had to hit a contractually obligated date, I would handle it totally different.

Your typical context is different from mine, I have been in large distributed projects but I prefer smaller localized ones. I can see how we put different weight to estimates.

I think my biggest beef is this “plans are useless, planning is essential” kind of thing (we seem to do one thing but what we really value is somewhat of a side effect). (TDD is not primarily about testing, estimating is not primarily about estimates and so on). So are we after a shared understanding or are we after estimates? A shared understanding could for instance give us an order in which things must be done, what can be done in parallel, what the minimal marketable feature is without having any time estimates at all.

I guess I would be more fine with the term “mind aligning” or something scary like that :)

I also think we tend to super size development more than necessary (generally speaking) and that creates situations that could have been avoided by actually scaling down and be more efficient. Teams don’t scale out linearly so to speak.

As an example in the other direction I am currently assigned to a small bank (loans, savings accounts) that has a full time development and maintenance team consisting of two people. The bank is very profitable by keeping things small.

Most development efforts can improve in so many dimensions and estimation is seldom the most worthwhile dimension to pick. Your estimation accuracy is most likely not your biggest problem.

Yeah… one of the best things about doing what i do for a living, is that you learn lots of ways NOT to build software organizations. I’m going to write a post on this someday, but one of the greatest cancers is selling features that you don’t have, under the assumption you can build it. When you are estimating to set an expectation around a fixed time, fixed scope, fixed cost delivery…. you are pretty screwed, no matter what you do. Build for the market, sell what you have, and learn from feedback to build more.

Last time the estimation/sizing debate took a round (about a year ago) I sat down to analyze what situations I saw story-point sizing of stories being useful. I found four questions that might be useful (depending on context) to get answered, and how estimation in story points can aid getting answers to those questions.

Incidentally, the first question I identified was “Is it small enough to fit in a sprint?”, and where estimating pushes the team to give some magnitude of the work to be done. Compare that with experience (what sizes have worked well previous sprints) and you can proactively help the team not to take on stories they will not be able to finish.

I find this analysis close to your argument of pushing a common understanding of what actually needs to be done.

Even if estimating was a mandatory, not to be questioned part of project management, I still think it is valuable to explore why we do things. When we understand why, we can do them with meaning, rather than simply going through the motions. That said, if you read the comments to this post, you’ll see that there are tons of folks in the agile community that don’t believe estimating is a valuable exercise. That said, these are all reasonable people, and it comes down to context. I’ve found that if you establish context first (something I didn’t do in this post) there is almost always some merit to any argument.

How about approaching it differently and agreeing on an investment amount that you are comfortable with for starters. The truth of the matter (for most complex problems) is that we only get a good sense of what will be involved the longer we are actually doing. Most customers don’t want to hear or be told numbers that exist at the wide range of the cone of uncertainty so what ends up happening is that we lie to each other and create a culture of mistrust.

If estimating needs to be done, I believe it should be done to get a sense of the risk involved in embarking on the initiative. To your example, my car broke down last year with a transmission problem. The people I called around had no clue what was wrong but for $500 they could pull it out take a look and tell me if I was going to need to buy a new transmission or it would be a minor fix to it. So I had options of investing $0, $500 or $500+.

Underlying almost every objection to estimating is an assumption that the organization is dysfunctional. IMO… refusing to estimate just exacerbates that dysfunction. It is possible to build a culture of trust where estimates are used for good rather than evil. We throw away a perfectly valid baselining technique because people don’t know how to use it properly. Again… there is another entire post or two embedded in my next comment, but I agree, especially at higher levels of abstraction, that we should think less about estimates and more about budgets. When I am working with teams on roadmapping or high level release planning, that is exactly how I guide the discussion. Given what the customer wants, how big do you think it is going to be? Now that we have set the parameters of the release, we no longer have an estimate, we have a budget… we have a constraint. Our job now is to deliver as much value as possible within the limits of what we have agreed to spend.

Mike said: “It seems to me you guys are really suggesting that our customers show up with a big pile of money and allow us to spend it two weeks at a time (or feature by feature) without ever having any understanding of the level of effort involved or where we might be when the money runs out? I challenge you to find any area in your life where you’d agree to that kind of a deal.”

Research works that way. You pour in money and you don’t know what will be discovered and that is perfectly acceptable.

Combine research with development and you end up having ‘pour in money’ to get some products out. The products you will get out will be new and disruptive and have a huge impact on your bottom line. If they are not good enough (not innovative, not disruptive), you decide not to sell them.

It is a totally different situation, if you modify or extend an existing thing.

However, the question is whether software to solve business problems is just a tool or in fact a new product. If you want to improve your business by means of software, then you better think about the research and development approach IMHO.

I agree… if the business is investing in research. I’m fine time boxing cost so we can do an experiment and learn. Most organizations are not investing in research, they are investing in development. They need to know how much of a certain product they can get by the time they need to be in market and some approximation of ROI. These aren’t experiments, they are business transactions. If everyone agrees we are doing research, investing in research, I agree… don’t estimate. I guess my point is, we can’t use language in our discussions that assume we are doing research (emergent outcomes) when we are really doing product development (convergent outcomes).

Isn’t software development in fact research and development in the original meaning of R&D?

There is the old idea of buying off the shelf software instead of developing your own. If you don’t want the risk but instead predictability, then maybe buying something and adapt slightly to it, may be the better decision. So many companies think they are special while in fact they are just another flavor of the same. Maybe they just need help to stop looking inward?

Shouldn’t we, as consultants, tell our clients about the true nature of software development instead of trying to find ways to make the unpredictable more controllable? Isn’t any attempt to control it in fact stifling innovation and a disservice as it prevents the discovery of smarter ways to perform some business action?

Stephan… It just depends on what you are going for from a business model perspective. Ideally, I think we need visionary product owners that lead the product based on frequent feedback from real customers, never making any external promises, with products so good that their customer base grows and grows. 37Signals comes to mind when I say this. They don’t care what I want as an individual consumer and they have never promised me anything… I pay them, they provide what they provide. They are 15 people or so.

Most of the companies that I work with are building systems of systems in highly competitive markets, with 100’s of developers, trying to coordinate ‘resources’ to get as much value as possible, and to coordinate the efforts of lots of folks. They have sales people that make promises based on the need to sell, rather than on the organizations ability to deliver. Many of these types of companies may die, but for now, many are trying to adapt.

So… when you are coordinating large investments, lots of people, in higher risk scenarios… my take is that we need to estimate. I think all of this comes down to ‘what’s your context’.

I spent a few hours talking with Tobias this weekend at the Agile Coaches Camp, looking for the places where we see the world the same, and why we may see things differently elsewhere. What I learned is that Tobias argues and writes from the ideal… but meets his clients where they are in practice. I tend to argue from a point of pragmatism, focusing on the ideal, but helping people understand that moving from a to b (the ideal) is often a non-trivial issue. I understand the POV of those that think estimating is waste… I get that there are probably more sustainable business models… but I don’t think it’s smart to give people that advice unless they have those business models. I’d like to help them get better at what they can do now.

Sounds a bit like a self-serving system that eventually goes from stagnation to death.

I’m more interested in uncovering smarter ways to develop software than in how to keep the “wrong” business model alive. Death is a part of life and so is the death of ideas and practices. Death is a way of freeing up space. Why not face it and accept the change?

Sales people like to sell an existing product. It is much more difficult to convince a customer to essentially become a partner in a new venture.

[…] November 21st, 2011 In a previous post I mentioned a post on Mike Cottmeyer’s blog entitled The Real Reason We Estimate. If you haven’t read it yet I highly recommend it. In the post Mike mentions that often, […]

[…] acknowledges that estimating for numbers is a tough step in software development in his post The Real Reason We Estimate. But Cottmeyer’s main point is that “Estimating is about creating a shared understanding of […]

I must have missed something here. No doubt estimating is difficult, particularly for pioneering endeavours, and we know that an exact estimate is an oxymoron, but without estimating how can we demonstrate that project benefits will exceed costs – a key project selection criterion surely?

Jim… I’m a big proponent of estimation. i just think the process of estimating can be more valuable than the estimate itself. At least in the kinds of projects and companies I work with. Software product companies. Lots and lots of people building stuff that don’t have shared understanding of what’s being built.