Agile India.

[Looks like the text entry window doesn't like quotes]

Hi Naresh,

As engineers we have to be aware of the business world needs as well, because after all, it is what drives engineering. I keep telling the engineers in my team to get MBAs even if they are happy in Engineering, because of how important it is for engineers to know a little of the business processes (versus demonizing the guys for taking classes like Math Without Numbers 101, etc.) :-) After all, even if we are technical most of us work in a for-profit business, like to get a paycheck, and should care whether the business side of your company is healthy or not.

I understand you feeling seeing yourself as a software craftsman, versus a simple 'engineer', a word that unfortunately society has made sound quite gray, almost automaton-like. In any case, even artist get commissioned to finish paintings on very specific dates (e.g. when the building or the park is finished and the inauguration ceremony is scheduled). The project manager will ask the artist how long the painting will take so he knows when the wall where the huge mural will hang has to be up!
Regarding your comments:

1) 'Bingo! If you know that you need your product on the shelves of Best Buy by Nov 15th, then how will your estimates help you making sure you have the product on the shelf?' Estimation tells me whether I can fit features or not ahead of schedule. Whether I need more people to fit the features. Whether more people will or won't help (the 'What one woman can do in nine months, nine women can't do in one month' problem.) Usually this works in two modes, a) if the customer sets the date, engineering sets the features, and vice-versa, b) if customer sets features, engineering sets dates. In either of these cases you need estimation. If I estimate that the features client/marketing want by August cannot be done, then I'll need more resources or drop features.

2) 'Assuming you have 6 months to build the product, you don’t need 6 months to produce the print/packaging material. May be you can start 3 months before Nov. Which means your organization has enough time to plan the other stuff and they don’t really need the estimates on day 1 of the project.'  I wish it was this simple, but as it turns out the materials have to be elaborated well ahead of time. My software had to be done months before the products go on the shelves, because for example,the ODM in China needed the code to integrated it into the OEMs VAR software, then they have to manufacture (and package) thousands of boxes, ship them by cargo ship to the US, and finally distribute them to the stores.

3) 'Luis, it would be great if you can share any project case study that you have estimated for. That would really help me.'
I was an embedded VoIP/telecomm developer for several years, later got into management and now I direct a softwre engineering department. For this particular project, my team developed and integrated the software for VoIP, wireline (LAN/WAN, RJ-45 ports) and wireless that many of the leading makers of VoIP-enabled routers (CPEs) use today, for carriers like Vonage, Sprint, Nortel, AT&T, etc. The boxes you see in Best Buy :)

I think there's a lot to be said about the misuse of estimation, more than it is useless. Just like metrics, I've seen estimations misused plenty of times at different companies, from dodgy promises from sales trying to get the customer to sign on the dotted like, senior management trying to show progress that doesn't exist, people asking for a accurate (and committing) estimate when the features are not even thought out and detailed, accepting estimates with a big +/- margin of error and then proclaiming to the customer these estimates as 'accurate-to-the-day', etc, etc. In any case, I'm glad you raised this issue, because even if I don't share the view that estimates are not needed, every well-established/accepted practice in the software development world has to be questioned periodically in order to improve it.

Thanks Luis, for your insightful comments. 

You are right, I'm a code monkey and I don't understand anything about business. But I don't agree with you that estimating is the only way to run a business.

Also I don't consider myself as a software engineer. I'm a software craftsman who consider that majority of software development activities are a craft rather than an engineering disciple. Engineering comes into picture when you compile your code or generate code.

Let´s say I have to have my product (e.g. a wireless router) on Best Buy shelves by November 15th, before the Christmas season starts. I have to produce the print/packaging material well ahead of time. I cannot design and print materials, packaging, documents, etc, listing features with a big “MAYBE” appended after each. The business world just doesn´t work that way.

Bingo! If you know that you need your product on the shelves of Best Buy by Nov 15th, then how will your estimates help you making sure you have the product on the shelf? I would turn around the question and ask by when do you need to start with all the other activities you have highlighted? Assuming you have 6 months to build the product, you don't need 6 months to produce the print/packaging material. May be you can start 3 months before Nov. Which means your organization has enough time to plan the other stuff and they don't really need the estimates on day 1 of the project.

Development (not coding) can start and in a few weeks you would have enough data to project it forward and see if you will meet the dead-line or not. If not, then you can de-scope sophistications of few lower priority features.

Luis, it would be great if you can share any project case study that you have estimated for. That would really help me.

The crux of this article is in the following phrase: 'One day it struck me that may be this whole practice is flawed and I’m not the only one who finds it difficult to estimate." Your research was not motivated by whether estimating is really needed or not (which all EM, PMs, PgMs, clients, and marketing/sales will tell you a clear YES) but rather because you are not good at estimating (a skill requirement for a software engineer). Simply because you are not good at estimating it doesn´t mean estimating is not needed. To comment on your statements:

1) "Estimates are a hang-over from the waterfall world." Actually, estimates are a hangover from the history of civilization... People have been estimating work in all industries since the history of man. In the software world estimates are necessary because, for example, based on them a project may or may not even move forward.

2) "What if I said 6 months and I delivered in 12 months?" Well, then I would not ask you to estimate anything again, as you need a lead maybe to show you how to estimate and make sure you don´t start on a coding trip to nowhere.

3) "Again do you really need to know now or you can watch the rate at which we deliver useful features and plan those other activities later?" For lack of a better word, this is miopic. Let´s say I have to have my product (e.g. a wireless router) on Best Buy shelves by November 15th, before the Christmas season starts. I have to produce the print/packaging material well ahead of time. I cannot design and print materials, packaging, documents, etc, listing features with a big "MAYBE" appended after each. The business world just doesn´t work that way.

4)"In most cases, it turns out that Estimation smells of lack of trust (because of past experience) and urge to push your risk on to someone else"  This is a bit inmature. Estimation, which you don´t like because you're not good at it, is only there because my boss hates me and misstrusts me. Please...

5) "... how much sophistication your users need? In most cases you don’t know this until you see your users (at least proxy users) use the feature. So why estimate upfront and miss the opportunity to collaborate with your users?" This demonstrates the thinking of a coder, not a software engineer who knows how to gather and define requirements BEFORE you start coding. Those requirements (and their estimates) can change once development starts, but that doesn´t mean you should not provide an estimate.

Estimating is not a bad thing, and changing project plans based on changing requirements is not a bad thing either, they are realities of the business world, and thus the engineering world.

Oh my, interesting discussion but unfortunately not real world.  A myriad of different types of estimates are needed (in fact, even more so when using SCRUM) but the magic is in how they are developed, used, communicated, and managed.  If team members are feeling micromanaged, then there is something wrong with how estimates are created and managed.  Identify cause and fix it.  Don't abandon a useful tool.  Estimates are often mismanaged, but are a tool to help the team deliver, and should be used as such.  Also, going through the process of estimating with the entire team helps provide a lot more clarity on the flow that is mentioned in earlier posts.  This is business.  Just the fact that we all have jobs and are involved with products/projects that deliver value, are a result of estimation.

I think that the paper http://www.poppendieck.com/righteous.htm could help in this discussion.
It is an analysis of the Lean way to contract, more like a parternership than a project.

I have to agree with Lisa on this one. The use of estimation in Scrum should result in a conversation that identifies the "sophistication" of the delivered product. In this sense, raw estimation without developed stories is not very useful.

But if we discuss the business need and are able to utilize proxy users we can reign in the "guess" significantly.

Although it is still an estimate, it will be a lot more valid with the exercise of information gathering and communication with all the interested parties.

The points to remember are
<ul>
<li>estimation is a guessing game and </li>
<li>the CONVERSATION (and resulting clarification and relationship) are what is most important</li>
</ul>

Estimation is necessary for ROI analysis. Everyone hates it and management is known to abuse it, but we write software to meet needs that can often be met in other ways. How can management reasonably make decisions on what to build without knowing the cost? How can management reasonably prioritize change orders without knowing the cost of each? In a world where decisions are made through comparative opportunity costs, estimation is essential.

Estimation is also necessary for coordination. Marketing needs to time their announcements, Documentation, QA and Release are downstream from Development and need to time their demands.

The problem is often in management, particularly non-technical management that doesn't understand estimation. Software estimation is inherently difficult because we don't write the same code over and over again. It's not like an auto repair estimate or a painting estimate. There are no books or tables. Many times the estimates are wrong - sometimes by 2X or 3X because a detail was overlooked and "the devil is in the details". Typically, estimates are under-estimates.

I like estimates that contain a variance like "5 days, plus or minus 2". Said another way, "3-7 days". The danger of the second way is that SOME management will hear the "3" and enter that into Excel or Project or some other tracking system.

Everyone wants to please their management so we want to be optimistic - don't. Be realistic.
I would encourage everyone in Development to consider their work in the context of the whole organization and embrace estimation

Andre, since we don't have iterations or sprints, we don't really have the concept of iteration planning meeting. Instead, what tends to happen is that the priority discussion happens very informally (no ceremony) on a continuous basis.

I'm not very comfortable with letting the customer decide just based on which is cheaper. I rather prefer giving the customer multiple potential solutions and having a joint discussion about what implications each one has. Once the customer has this info, it becomes relatively easy for us to make informed prioritization decisions.

This works well when the customer has to decide to include a feature or not. But what if the customer has to pick one between 2 things. Again, I don't think its fair to ask the customer to pick an engine or a steering wheel. Both are very important for a car to function. Similarly in software a lot of times, couple of features together makes sense. So instead of building one feature perfectly and then the next feature (sequentially), I would stive to find a way where we can build both the features but with a lower sophistication. And then gradually increase their sophistication.

Lisa, you have a very valid point and I completely agree with you that this discussion is very important. Personally I prefer calling out the real intent rather than having it hidden behind something else.

With the discussion on acceptance criteria and thin-slice approach, we seem to achieve a lot of what you are highlighting.

Discussing acceptance criteria really helps us understand the motivations and hence helps us come up with multiple potential solutions. Most customers I've worked with enjoy being presented options. Its gives us an opportunity to collaborate and decide options together.

The nice things I like is our focus is very clear and we don't seem to be lost in auxiliary stuff like estimates.

In the 5 years that my team has been doing Scrum, I've seen an evolution in estimating. At first we had regular estimation meetings. We saw they were mostly a waste of time. I remember we estimated one story at 3 points, when in truth it turned out to be a theme and probably 20 points. Also, we estimated dozens if not hundreds of stories that never got prioritized into a sprint.

Our business folks still want an idea of how much a feature might cost. We might give them a rough idea at the theme level to help them decide if the feature has a good ROI. We still do estimates, usually right before the sprint where we'll do the stories or sometimes we plan a theme of a few iterations' worth of work. It's more of a chance to ask questions and understand the stories. Also, we might identify a feature as being very expensive, and work with the business to see if there's a simpler alternative. I think the discussion is important, not the estimates. So if a team doesn't do estimating meetings, they still need to be sure to have these conversations with the customers.

Naresh, namasté!
With no estimates, have you also eliminated the planning game?  I can't see another way to ensure the customer has a chance to change their requests based on what is inexpensive to implement.   Other than that I like the idea of budgeting instead of estimating....

My personal opinion is Estimation everything to detail at the very beginning is not very useful but estimation at high level is still necessary and can be useful to some extent. There is no tool good enough in this world that could solve every problem to the best. so to debate whether esitmation is harmful or not by giving all sorts of examples to convince each other won't work. In my opinion, we still need estimation at high level so we have some ideas to make appropriate preparation for it; and then at low level, do some initial feasibility study, seek feedback and input from potential customers before commence the development work for the whole project. Regularly review and adjust on the way to adapt to the change. Of course at the cost of time, budget and resource adjustment that all parties particularly customers should be aware of.

As of the " tiger skeleton" example in Yasin Hamid reply: I think it's a bit different. As I see a cat was delivered instead of a "tiger" (product) as a birthday gift to his daughter (customer). Cat looks similiar to tiger from face. but they are indeed very different animals (features). And most important, her daughter (customer) doesn't have a requirement first before her birthday about how this gift tiger (product) should be. therefore he (development) could deliver something else with great similarity or even something else. If she doesn't particulary require a tiger, why have to be tiger, why can't he buy something else at the same cost (budget). However if his daugher clearly state in her request she wants tiger skeleton before her birthday, we can estimate roughly how much it got to cost to buy one or how long it will take to build one, then decide whether it is doable or not. then either buy one to save time (deadline), or build one to save money (budget) or change to other gift similar (change scope). If no pre-estimate, then it will lead to panic at last minute of upsetting her (the customer).

Most companies have one or two situations, either a hard deadline that cannot be missed, OR a customer (internal/external) who needs to know when to expect the product to arrive. In either case you are going to need some means to measure how you are doing so you can either make necessary adjustments

Absolutely! Measuring the rate at which you are completing (deploying) fully tested features can be a great measure. Not sure if you really need estimates for this.

What about fixed bid projects?

As far as fixed bid projects go, IMHO they are broken promises. I've been a part of various fixed bid projects and I've seen quality suffer. Also most companies who do fixed bid projects use change-requests as a business model.

What if your marketing department came to me and told you that "we have x customers who will buy this product if they have "blah" feature by some deadline".

I would assume the feature is fairly high-level at this point. (If not, it would be trivial to do it any which ways).

By looking at the large feature you can say if you are looking at a fish or a whale. (some initial impression of scope). So without doing any detailed estimates you can say at a very high level if its possible or not. If in doubt, it means you can probably give it a shot.

If you think its something that can be done, then you start playing around with the scope. You start slicing the feature from end-user's perspective. Start building the thin slices starting with highest priority ones. When the deadline hits you, best case, everything is done. Worst case you have highest priority thin-slices working. By focusing on thin slices I've found myself saving a lot of time by eliminating low priority thin slices.

I assume that you are not going to get into a legal contract before you begin some development. (Instead of spending time on detailed upfront planning and estimation, we start spiking out the feature. This gives us more confidence than just estimating). May be after a couple of weeks you can judge how your development is going and then decide to go into a legal contract with your potential customers.

Before the legal contract is signed your marketing team can assure the customers that your team is working on the feature. You even take their inputs when prioritizing your thin slices. You involve them in your reviews. This way they get hooked in. And will most likely sign the contract. (possibly at a higher rate than you could have charged before, because they now believe in your team's capability)

@Yasin, thanks for your comments. I feel the tiger example is not very applicable to software projects. I've yet to work on a project where things were as clear as "we want to build a tiger". In most cases all we know is
<ul>
<li>we want something that can be gifted.</li>
<li>It should not scare a person below 10 years</li>
<li>It should represent something that is like a real world entity, an animal is preferred</li>
<li>...and so on...</li>
</ul>

One needs to still explore the problem domain to come up with some potential solutions. And in some cases we might want to spike or prototype a couple of options to decide which way we want to go.

I found your post very interesting, but there are some parts which I disagree with. I agree that sometimes the estimates are useless, hard to do or abused by management. Nevertheless I think if they are properly used they can be very useful. I would go even further and say that I would go to a project without proper estimates. I had a recent experience as a contractee/customer. The project of course went over budget and overtime, but the overrun was in the buffer zone I expected, so nothing tragic happened. But without estimates it would go much much over budget and it would ruin me. After looking at estimates I removed some features completely and cut some others.

The problem is that sometimes there are no most important and less important features, sometimes the features depends on each other. I call this problem "a tiger's skeleton problem". Imagine you want to give your daughter a tiger for birthday. So you need a whole tiger done before certain deadline and in certain budget. You definitely don't want to end up with perfectly working skeleton on your daughter's birthday. You can imagine her shock once she opens the box and finds a pile of bones. It won't help telling her that she will soon get muscles... I guess If you knew you would rather got her a cat, which would fit in the budget and time.

I don’t think you can completely escape this situation. There will always be people that want everything on their terms without regard to reality.

The inertia of estimation filled ways of doing things need to be reversed. It needs education and demonstration. Seeing is believing. But after all that they still want to live in their fantasies, then I would say let them have the cake and eat it too. We can always find greener pastures.

Power message with a lot of good points. I often struggle with the problem of providing estimates that will hit a specific deadline while providing enough value to justify a release. I think the key is setting management expectations while managing scope to meet the deadlines. It often works until you encounter the stakeholder that wants to specific scope, schedule and resources without specifying the requirements (refined scope, i.e. the details) until after the project is underway. Much like your one day vs. one month login page problem. When estimating I am told make it simple and when implementing I am told make it simple with these complex features.

I don't think you can completely escape this situation. There will always be people that want everything on their terms without regard to reality.

I have also found order of magnitude estimates to be good enough for a lot of business planning. Often the business goals are or a go/no go nature that don't really require in depth estimates that take a long time to develop.

@Jamey, In my experience having estimates encourages more micro-management.

You mentioned that with estimates you are able to set appropriate expectations with your Executive Management. How confident are you about those estimates? Do you think they are optimal? Do you think your team can be done much faster in some cases? Do you think your team has enough context to be able to weigh all their options and give you an optimal estimate? What happens if 3 weeks after your estimation and planning, someone releases an open source tool that can do most of what you want to do? Would you still build the software yourself instead of leveraging on that one? There seems to be so many possibilities, how can one account for all these?

Have you tried taking a project plan to your Executive Management that says we'll meet every week to see real tested functional features working. Based on the first few meetings, we can jointly decide how we want to strategize our product? May be seeing a few working features might spark some excellent ideas that we can't think of now.

I cannot support the theory that creating an estimate is harmful/wasteful. In product driven companies it is virtually mandatory. As the Director of an R&D team I promote agile practices (across the board) and strongly believe in collaborating; prerequisites for the entire team. These are not novel ideas or unique concepts but requirements for an effective R&D team.

I use estimates for budgeting purposes, risk analysis and many other real world necessities in new product development. Although cumbersome estimates serve a real need for management personnel. For me it is not about trust or ensuring competence; it’s about not needing to micromanage a project or engineer. It is also about setting the appropriate expectations with Executive Management. I cannot image taking a project plan to an Executive Management committee and not having an estimate; it’s just part of the deal.

In one of your responses you list marketing updating their features list as a reason why not creating the estimate is wise. A strong new product development process anticipates feature creep and has mechanisms built in to address. As you are well aware of nothing is free in this world and when something is added it has a cost (monetary and/or time).

I hate to sound so against this concept and maybe it fits other industries (i.e. service, finance).

@Ellen, only if metrics could solve my problems, I would be a better man. While tools and metrics provide useful information, they don't really solve the problem. Tools are tools. They should be used by concerned people to solve problems at hand. Just because the tool provides feature x, does not mean I'm going to go crazy with it.

I need to amend my previous post. I suggested that "Management needs these" ...

I meant, management of the agile processes (for the benefit of both developers and management) - but also the tools provide so many metrics that are useful for all.

I am generalizing here on the tools - since way too much to cover in terms of their benefits and capabilities for developers, as well as management. Plenty/ more tangible details on these at Atlassian's site, of course.

I'm not sure I can completely agree with you that estimations is harmful or also something you can completely do without.

But I do think it needs to be based on reality, and flexible with reality as well - and so do this requires tools that allow for this.

As I am sure you know (and maybe use), Atlassian tools provide alot of metrics in their different packages (JIRA, FishEye, Crucible, Clover, and integration points for Confluence WIKI and Bamboo) for many different purposes. Management not only needs these but in my experience, demands these. The visibility though is also useful for developers.

Nonetheless, whether a developer agrees with their usefulness of not, is not the point. The developer alone is not the only person in the business typically - and therefore, metrics, which can help with estimations are critical on numerous levels (tracking, prioritizing, reality checks, resourcing, business/customer commitments, etc).

Here is what Joshua Kerievsky has to say about Estimation : Estimating Considered Wasteful: Introducing Micro-Releases http://submissions.agile2008.org/node/4804

One person responded to this post saying:

While it might be nice to 'focus on the flow of the deliverable' that isn't unfortunately very practical in much, or more likely MOST, of the real world. You have customers who want to know when it's going to be available so they can plan rollout, trainign, etc. Sometimes you have things that NEED to be done by a specific time in order to meet real world needs. Turbotax has to have their next version out in time for the tax season, HR vendors like the one I work for have to address IRS rule changes and get versions out in time for when customers have employees going through open enrollment.. NASA has launch windows for vehicles where you either make the window or don't go at all. The examples are many and I'm sure we could easily add to my examples.

Heck for any software that's not being built for a specific customer, you have considerations of launch events, marketing plans, etc etc.. and all of that needs to know both WHEN will the software be ready, and WHAT features will be inside.

So I frankly don't think estimation is a hang-over from waterfall but more a requirement of many businesses and hence something that is needed no matter what process you use to build the product. Deadlines exist all over the world in most kinds of businesses, it's not unique to software, nor does software get to be exempted.. Just about every 'customer' (whether it's the one paying the bills, or your sales/marketing dept) needs to know 'when will it be ready', and that means you've got to have some way to come up with a reasonably accurate answer.

My response:

You seem to contradict yourself here. On one hand you are saying that every business has real deadlines and on other hand you are saying that they need accurate estimates (oxymoron) for 'when will it be ready'.

If business have real deadlines, then how does your estimates really help? What you need to do in this context is take the deadline and work backwards. You need to budget functionality and not really estimate them.

If you are always building the highest priority things first and maintaining your projects in deploy-able state, then when the deadline hits, you have the most important features that could be completed in the given time ready. Note that its different from saying what ever is done is what is done. Its saying that we have control over what gets done and lets together build the best we can in the given time.

Ideally you want to deploy the application a few times before the deadline so that you have wrinkled out any production issues and also got a good amount of feedback from potential users as early as possible.

Another thing I commonly hear is without estimates how do we do capacity and resource planning. This reminds me of Mythical Man Month. If your estimates shows that the project is large, then you add more people to it and hope that the project will finish faster. This is not practical. You always start with a small team and grow it as necessary.

Looking at the software shape every week or so, gives other departments like marketing and training enough time to plan their activities.

What I find a lot of times in product companies is you start building a product with an initial vision with a set of features that you consider are your USP (Unique Selling Proposition). A few weeks later, you might come up with a new feature which actually becomes your killer feature. Marketing just based on the initial list of features seems immature.

In my experience if just the software team is agile it really does not help. Its local optimization. All the departments in the organizations including recruitment and HR have to be in harmony (inspect and adapt).

Another thing I want to highlight here is, some people think planning = estimation. They are 2 different activities. To me planning means setting goals and having a vision. Also planning is not a one time activity. Its an ongoing activity. I usually like to say "We plan to deliver NOT deliver to a plan".

This is interesting... alot of projects get hung up on this very thing! more important to have good methods and an experienced team who can collaborate well.