Giving estimates for large scale projects in an Agile Environment [closed]

Question

My firm just got its first large-scale development project inquiry and I would like to use an Agile process. The client has a vision for the application but openly admits to having very few requirements and recognizes that we will have to charge by the hour. Because of this, I've all but sold him on an Agile approach.

The problem is that he wants a figure to budget around. I've read a number of articles that pretty much advocate against giving up an estimate because the client will budget for that number and even as requirements change, the number in their head and in the books doesn't.

I've read there are a number of ways to factor in pricing in the contract, but almost all of them (save one) incorporate an up-front number. This just seems to violate the entire set of principles of Agile development.

So my question is, if you're an Agile shop, how do you manage to circumvent this Catch-22 of Agile development?

Hedonic

Excellent question. I'll be interested to hear what folks with more agile consulting experience say. I'd guess there is no option but to go to a "time & materials" model but obviously your client wants otherwise. – Johiah

Good one. I have been asking myself the same question. Without an upfront detailed analysis is hard to give a realistic estimate and therefore offer a price to the client. Usually there are several companies biding for the given project and the client among other factors will choose considering the lowest price. – Speechless

Have you made sure that you and the customer share an understanding over the relationship between time and budget? As we all know, time is money in that everyone working on the project needs to be paid. Therefore it's incongruous to consider delivery time and budget seperately. The customer needs to realise that if you take longer than (budget)/(hourly rate) it means that it is they who are doing the work, while you wait for something from them. Otherwise, how is the extra time being paid for if the budget is fixed? – Rik

Answer 1

Here's the fundamental question.

When will the client think they're done?

If they think they'll be done by June, then you put an Agile team in place. That's 4-6 people for 6 months. That's the budget. Essentially, you do the multiplication for them. team * rate * 6 months.

If they think they'll be mostly done by June, but there will be more work after that, then you're possibly looking at 9 months of work. Again, you're just doing a multiply that they could do for themselves. team * rate * 9 months.

If they think that you'll be their development team for the foreseeable future, give them a price that will get the project through to the end of the year. team * rate * 12 months.

Since each release is an opportunity to reprioritize, you should be pricing each release as as separate piece of work based on the things you will get done in that release. Since it's their priority scheme, they control what you build, they control the budget, phase by phase.

Often your client really wants to know how much a particular feature set will cost. Instead of ask that, they ask about overall budget (which is silly). Spend a lot of time on the first release showing what they get and how much that first release will cost.

Eventually, they'll see the fundamental truth.

They're buying the features from most important to least important. If they prioritize correctly, they can stop spending money at any time and have something useful.

Done is a relative term. Some projects are "done" because there's no more money. Others are done because there's no more time. Rarely (at least in software development) is a project ever done because we ran out of things to do.

Kinghood

Fantastic points man, although my circumstances prevent me from simply doing the multiplication in that fashion. However, if we break up the sprints into time increments and then estimate the number of sprints, could give an estimate that way. – Hedonic

Also, I had never thought about the importance of prioritization that way. I think there should/could be at least one low-priority sprint first so that trust can be built and to provide a general understanding of how the process works. Overall, great tips. – Hedonic

@Chance, you can pretend to do more detailed estimates. But, ultimately, unless you have a contractual commitment to specific implementation details, all you're really doing is budgeting for the time it might take. It makes mgrs. happy to think your thinking. Even when you're guessing. – Kinghood

Answer 2

For this situation, we've provided an estimate for the first chunk of work, and then let the client purchase more sprints as required to complete the work to the desired level.

As you get more of the system developed, and incorporate feedback from the client into the sprint deliverables, you will both get a better feeling for the amount of work involved, and hence the costs involved.

Edit: Cool. Way excellent! From the fact that you've sold them on an Agile approach, BTW good one!, chances are you will be able to seel them on approaching it from an agile point of view in terms of features to be implemented. Maybe have a listen to this "Intro to Scrum" podcast. You might be able to sell them on the fact that they probably won't need to have all the bells and whistles that they think tha they need right now.

HTH

cheers,

Rob

Stlaurent

Right - this is the approach I am trying to sell the client but I sense that they are trying to budget out the total cost of the application. – Hedonic

Answer 3

Look, there's a core fact here. You will be asked to estimate cost, contract for a particular delivery date, and commit to a full set of delivered features.

You can't do all three.

Not "you shouldn't" or "it would be wise not to"; you (for all practical purposes) can't. By which I mean that the probability of successfully doing all three is extremely small.

The best answer is to commit to a cost and schedule, and to an iterative process with quick iterations and regular feedback, and then write the agreement so that what is done unde the fixed cost and schedule is what will be delivered. That is, you keep delivering new features (and modifications) until the time and money runs out.

The truth is, even if you do sign up to all three, the best you'll ever be able to do is two out of three anyway. Might as well be open about it.

Kling

This is a very interesting approach, and although I would love to implement it, I feel it requires a great deal of trust from the client. As such, I will likely need a few more large projects before I can consider using it. – Hedonic

Chance, the thing is, this isn't an interesting approach, it's a law of nature. Whatever you tell your customer, you'll be faced with the reality. – Kling

This is the most honest perspective of real day to day work. I totally agree on this, believing the opposite, either you are lying to yourself or to your client. Also, you should be very careful if you're asked to sign an agreement that commits you to all this three, since it's most likely you'll fail. – Minority

Answer 4

Here's how a crusty old government contractor I know recently put it: "As the prostitutes say, first you gotta get them upstairs."

That doesn't answer your question, but it's worth remembering. If they won't come upstairs without number up front (and they won't), you have to give them a number.

Anybody sponsoring a software project needs to have an idea of what kind of return they're going to get on their investment, so that they can evaluate whether or not the investment is worth making. A project may be worth doing if it costs $1m and takes 12 months. It may not be worth doing if it costs $2m and takes 24 months.

The real question is: can you do this project within a time frame and budget that makes it possible for the client to realize an appropriate return on their investment? If your answer to that question is anything but "yes," then they shouldn't hire you to do the project. Otherwise, they're just spending money and rolling the dice.

If your current answer to that question is "we don't know yet," then they shouldn't hire you to do the project. But that doesn't mean that they shouldn't hire you to find out whether or not the project is worth doing. A good consulting-firm buzzword for this is "preliminary scoping exercise."

Agile development is about managing a curve in three dimensions: money spent, calendar time, and feature set. It's a given that if the budget and schedule are fixed, the feature set must be variable. You can't know what the final feature set will be, given those constraints. But you can know if a feature set that you'll be able to produce within those constraints falls inside a range that your client will find acceptable.

You can know this, and you can find it out. Finding that out is something that your firm can do and your client can't. It's a service that you can provide to them and that they should pay you for. Avoid the temptation to do this for free and call it a cost of sales. Project scoping is every bit as much a part of professional services as software development. You're not doing this to close a sale; you're doing this to help your client make a business decision that they don't yet have enough information to make.

But first you gotta get them to come upstairs.

Aegeus

Brilliant response, I think you are absolutely right in every regard. The first time I read it, I thought it was an "if" we are capable of actually writing the code, but its more "if we can produce the code in X time for Y money" which makes a hell of a lot more sense. – Hedonic

And you are right on the money about getting them upstairs - once 'upstairs', or into the project and the client realizes that the number was off due to their specifications, they can choose to break the contract. One question though, if they choose not to go with the sale, do you still invoice? – Hedonic

The point of agile development is avoiding the situation where "do you still invoice?" is a question on anybody's minds. The client's going to reap the rewards if the project is successful; the risk is also rightly his. Your job is to mitigate the risks you can and inform him of what you can't. – Aegeus

Answer 5

These answers are really great. I don't have a lot of experience to share, but I thought of an analogy:

Last year my wife and I remodeled our kitchen. The contractor proposed billing on time & materials instead of giving an estimate, because we didn't know what we'd discover with respect to plumbing, subfloor damage, and so on. We agreed, because I'm working from home and I was available continuously to answer questions. The contractor and I had a good rapport so when something came up, he felt free to knock on my office door and we'd discuss it. Decisions got made quickly and the work was done the way I wanted it. That seems similar to the Agile priority on frequent customer review.

By contrast, my wife's cousin is also remodeling his house. He's an ER doctor and he is not available on site during the remodel. So he described being regularly surprised by the contractors making major decisions without consulting him ("What? I didn't want that picture window blocked off! Tear out the wall and reframe the window the way it was!"). This is of course painfully expensive and blows the schedule out of the water. Definitely not Agile.

So one way to convince a client that a time & materials mode will work may be to assure them you'll make frequent progress reports to get their feedback. I believe this is already a core recommendation of most Agile methodologies. To begin, of course this requires the customer give their trust to the consultant.

As a separate resource, I searched and found a book on this subject: "Agile Estimating and Planning" by Mike Cohn. Read the praise quotes on that page, from an impressive set of Agile experts.

Johiah

Answer 6

First of all, I want to say I think it's great you've sold him an on agile approach and per hour pricing. That's very hard to do.

Regarding your dilemma, I think you should present him with a rough pricing estimate and the features / scope it includes. During the development process, if you see something important coming up that will change the scope / cost, you say to the client "stop - this is great, but understand that it changes the original scope we discussed."

At this point the client has the privilege of agreeing, being aware that he will pay more than he originally thought, or halting the new development for now. Many agile projects are built in many mini-stages - for which you can give pretty accurate estimate of price / time. Before any new mini-stage commence, it's important that you and the client see eye to eye on what is up next and how much time / cost will be spent on it.

Wendish

The problem is that although the client may know what he wants, the idea of how to get there isn't clear. This lack of a solid plan leaves holes in my ability to give anywhere near an accurate quote up front - but he still wants one. – Hedonic

You have to give him something. You should have a good idea of how you will start at least, so give him a rough estimate for a first stage with reasonable specification of scope / features. Always estimate a short distance into the future, this will at least give him some measure of cost. – Wendish

Sorry this isn't really Agile. Its fixed scope with a minimal cost for change. – Recall

Answer 7

As always there's quality, functionality and time (=resources) which are your main parameters. We're not messing with quality any more, so there's only features and resources left. Fairly often you can get away with convincing that a certain amount of resources will at minimum reach a certain feature set. So as long as you can find an amount of resources that delivers a plausible feature set I believe this is enough for quite a few customers. The upside is that they can control progress while on the move, and there's always the option of backing out.

Rectilinear

If I understand you correctly, I think this is along the lines of what I was thinking. I'm trying to convince him to allow me to give an estimate at each sprint, as I'll have a solid grasp of what's due but as many clients, he wants an overall estimate. – Hedonic

Well you could ask him for "6 sprints. We can do all the pri 1 stuff in 4 sprints". – Rectilinear

Answer 8

The way that I have done this is to use my current velocity and estimate a range based on rough estimates of complexity (number of stories). You would update this as you begin planning the application so that the range estimate gradually becomes better and better.

For example, give an estimate from 6mos to 2 years (if you're sure that it will take less time than 2 years. As you break it down into features, then plan for those features, you come up with better and better estimates so that after 6mos you can reliably say (absent any other changes), we'll be done in another 2-3 months (total of 8-9 months). Eventually, you get to the point where you can say, we'll be done after the next iteration (2weeks to 1month).

You need to pair this with letting the customer know that adding features will increase the time to completion, then let them decide how to proceed -- either drop the feature or increase the time. For any given project, scope and time are really the only variables that you can effectively change. Quality and resources are pretty much fixed. Actually, you can add resources, but generally you see an increase in time and decrease in quality initially so this only works if your time horizon is long.

Deflect

This seems like a good technique but he seems fairly flexible with time, its the budget that hes concerned with. – Hedonic

Answer 9

This was my answer to a closed question related to story points. I use this all the time for macro estimation.

When I switched to points, I decided to it only if I could meet the two following points; 1) find and argument that justify the switch and that will convince the team 2) Find an easy method to use it.

Convincing

It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.

This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.

Putting Points in the Backlog

This step is done with the participation of the entire scrum team.

Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.

Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.

NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.

That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.

Velocity & Estimation (macro planning)

To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.

That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value

Triumvir

Answer 10

If you have successfully sold the customer an on Agile approach, and billing by the hour, do not give them an estimate for how much it will cost to complete the project!. Even if they say they want it only for budgeting purposes, do not do it!.

The reason is that any estimate of cost will come to be treated as a definite commitment; no matter how many times you say it isn't, and how many times the customer says they understand that, it will be treated as a commitment. Even if the customer understands, their boss won't, and although they won't be able to legally force you to deliver for the price you said, you will come to known as a company that doesn't deliver what it promised. Providing an estimate throws away all the advantage of being agile in the first place.

What I suggest is telling them that you will spend no more than such-and-such an amount before the end of the financial year (or whatever other billing period your customer is interested in). That should be enough for them to plan financially without in any way saying that the project will be finished by then.

Ney

Answer 11

This is a really tough issue. See what Robert Glass has to say on the subject in his book "Facts and Fallacies of Software Engineering". (Note that Amazon has books available new for less than they're available second-hand! [as of 2009-01-05 12:20 -08:00]; also at Google books.)

Rhetic

Answer 12

One approach you could take is to give the client a general estimate that you believe is relatively close. Also give a percentage. The percentage will be an increase or decrease allotment in the budget due to changing requirements.

Example: General estimate of $10,000 but since the requirements are vague and the project could change course easily there is a +/- 30% price adjustment option.

This way the client can have a general idea of what to budget and you have some flexibility in charging to the project.

Millepede

I've read that even with this approach, you are still deadlocking yourself in because the client will take the low/high and convert it into a quote, rather than an estimate. In the worst-case scenario though, this may be ideal. – Hedonic

your absolutely correct, just trying to get some ideas out there. thanks for the feedback. – Millepede