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.
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.
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.
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.
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.
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.
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.
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.
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.
这是一个非常棘手的问题。 看看 Robert Glass 在他的书“软件工程的事实与谬误”中对此主题有何评论”。 （请注意，亚马逊的新书价格低于二手书！[截至 2009-01-05 12:20 -08:00]；Google 图书上也有。）
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.)
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.
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
发布评论
评论（12）
这是基本问题。
客户什么时候会认为他们已经完成了？
如果他们认为他们会在六月之前完成，那么你就会组建一个敏捷团队。 也就是 4-6 人 6 个月。 这就是预算。 本质上，你为它们进行乘法运算。 团队*费率*6个月。
如果他们认为大部分工作将在 6 月完成，但之后还会有更多工作，那么您可能会考虑 9 个月的工作。 再说一次，你只是在做他们自己可以做的乘法。 团队*费率*9个月。
如果他们认为您在可预见的未来将成为他们的开发团队，请给他们一个能够让项目完成到年底的价格。 团队 * 费率 * 12 个月。
由于每个版本都是重新确定优先级的机会，因此您应该根据您将在该版本中完成的事情将每个版本作为单独的工作进行定价。 因为这是他们的优先计划，所以他们控制你构建的内容，他们控制预算，逐步进行。
通常，您的客户确实想知道特定功能集的成本是多少。 他们没有问这个，而是询问总体预算（这是愚蠢的）。 在第一个版本上花费大量时间来展示他们得到了什么以及第一个版本将花费多少。
最终，他们会看到根本的真相。
他们购买的功能从最重要到最不重要。 如果他们的优先顺序正确，他们可以随时停止花钱并拥有一些有用的东西。
完成是一个相对术语。 有些项目“完成”是因为没有更多的钱。 其他的都完成了，因为没有更多的时间。 很少有项目（至少在软件开发中）是因为我们无事可做而完成的。
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.
对于这种情况，我们提供了对第一部分工作的估计，然后让客户根据需要购买更多的冲刺，以将工作完成到所需的水平。
随着您开发出更多的系统，并将客户的反馈纳入冲刺可交付成果中，您将对所涉及的工作量以及所涉及的成本有更好的感觉。
编辑：酷。 太棒了！ 事实上，您已经向他们推销了敏捷方法，顺便说一句，这很好！，您很可能会看到他们从敏捷的角度来实现要实现的功能。 也许可以听听这个“Scrum 简介”播客。 你也许可以卖掉他们，因为他们可能不需要拥有他们认为现在需要的所有花里胡哨的东西。
HTH
干杯，
罗布
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
看，这里有一个核心事实。 您将被要求估算成本、签订特定交付日期的合同，并承诺提供全套功能。
你不能同时做这三件事。
不是“你不应该”或“最好不要这样做”； 你（出于所有实际目的）不能。 我的意思是，成功完成这三件事的可能性非常小。
最好的答案是承诺成本和时间表，以及快速迭代和定期反馈的迭代过程，然后编写协议，以便在固定成本和时间表下完成的事情将是被交付。 也就是说，您不断提供新功能（和修改），直到时间和金钱耗尽。
事实是，即使您确实注册了这三个项目，您最多也只能选择三分之二。 不妨对此持开放态度。
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.
我认识的一位脾气暴躁的老政府承包商最近是这么说的：“正如妓女们所说，首先你得把她们弄上楼。”
这并不能回答你的问题，但值得记住。 如果他们在没有事先提供号码的情况下不会上楼（他们不会），您必须给他们一个号码。
任何赞助软件项目的人都需要了解他们的投资将获得什么样的回报，以便他们能够评估投资是否值得。 如果一个项目花费 100 万美元并需要 12 个月，那么它可能值得做。 如果花费 200 万美元并且需要 24 个月，这可能不值得做。
真正的问题是：您能否在时间范围和预算内完成这个项目，使客户能够实现适当的投资回报？ 如果你对这个问题的回答不是“是”，那么他们就不应该雇用你来做这个项目。 否则，他们只是花钱掷骰子。
如果您当前对该问题的回答是“我们还不知道”，那么他们不应该雇用您来完成该项目。 但这并不意味着他们不应该雇用你来确定该项目是否值得做。 咨询公司对此的一个很好的流行语是“初步范围界定练习”。
敏捷开发是关于管理三个维度的曲线：花费的资金、日历时间和功能集。 如果预算和时间表是固定的，那么功能集必须是可变的。 考虑到这些限制，您无法知道最终的功能集是什么。 但是您可以知道您在这些限制条件下能够生成的功能集是否在您的客户可接受的范围内。
你可以知道这一点，也可以找出来。 找出这一点是你的公司可以做的事情，而你的客户却不能。 这是您可以向他们提供的服务，并且他们应该向您付费。 避免免费这样做的诱惑，并将其称为销售成本。 项目范围界定与软件开发一样都是专业服务的一部分。 您这样做不是为了完成销售；而是为了完成销售。 您这样做是为了帮助您的客户做出他们还没有足够信息做出的业务决策。
但首先你得让他们上楼。
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.
这些答案真的很棒。 我没有太多经验可以分享，但我想到了一个类比：
去年我和妻子改造了我们的厨房。 承包商建议按时计费。 材料而不是给出估计，因为我们不知道我们会在管道、底层地板损坏等方面发现什么。 我们同意了，因为我在家工作，并且可以随时回答问题。 承包商和我关系很好，所以当有事情发生时，他会随时敲我办公室的门，我们会讨论。 决定很快就做出了，工作也按照我想要的方式完成了。 这似乎与频繁客户审查上的敏捷优先级类似。
相比之下，我妻子的表弟也在改造他的房子。 他是一名急诊室医生，在改造期间他不在现场。 因此，他描述了承包商在没有咨询他的情况下做出重大决定的情况，这让他经常感到惊讶（“什么？我不想让那扇观景窗被堵住！把墙拆掉，把窗户改成原来的样子！”）。 这当然是非常昂贵的，并且使日程安排变得毫无意义。 绝对不是敏捷。
因此，让客户相信时间和时间的一种方法是： 材料模式的作用可能是向他们保证你会经常制作进度报告以获得他们的反馈。 我相信这已经是大多数敏捷方法论的核心建议。 首先，当然这需要客户信任顾问。
作为一个单独的资源，我搜索并找到了一本关于此主题的书：“敏捷估算和规划< /a>”，作者：迈克·科恩。 阅读该页面上来自一群令人印象深刻的敏捷专家的赞扬语录。
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.
首先，我想说，我认为您向他推销了敏捷方法和按小时定价，这非常棒。 这很难做到。
关于您的困境，我认为您应该向他提供一个粗略的定价估算及其包含的功能/范围。 在开发过程中，如果您发现一些重要的事情即将发生，这将改变范围/成本，您可以对客户说“停止 - 这很好，但要明白它会改变我们讨论的原始范围。”
此时，客户有权同意，知道他将支付比最初想象的更多的费用，或者暂时停止新的开发。 许多敏捷项目都是在许多迷你阶段中构建的 - 您可以对此给出相当准确的价格/时间估计。 在任何新的迷你阶段开始之前，重要的是您和客户对接下来要发生的事情以及将花费多少时间/成本达成一致。
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.
与往常一样，质量、功能和时间（=资源）是您的主要参数。 我们不再搞乱质量，所以只剩下功能和资源了。 通常，您可以确信一定数量的资源至少可以达到特定的功能集。 因此，只要您能找到大量资源来提供合理的功能集，我相信这对于相当多的客户来说就足够了。 好处是他们可以在移动中控制进度，并且总是可以选择退出。
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.
我这样做的方法是使用当前的速度并根据复杂性（故事数量）的粗略估计来估计范围。 当您开始规划应用程序时，您将更新此信息，以便范围估计逐渐变得越来越好。
例如，给出从 6mos 到 2 年的估计（如果您确定所需时间少于 2 年）。当您将其分解为功能，然后规划这些功能时，您会得出越来越好的估计，因此6 个月后，您可以可靠地说（没有任何其他更改），我们将在另外 2-3 个月内完成（总共 8-9 个月）。最终，您可以说，我们会完成。 您需要在下一次迭代（2 周到 1 个月）后完成，
让客户知道添加功能会增加完成时间，然后让他们决定如何继续 - 要么删除该功能，要么增加时间。任何给定的项目，范围和时间实际上是您可以有效更改的唯一变量质量和资源几乎是固定的实际上，您可以添加资源，但通常您最初会看到时间增加和质量下降，所以这才有效。如果你的时间范围很长。
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.
您可以采取的一种方法是向客户提供您认为相对接近的总体估计。 还给个百分比。 由于需求变化，该百分比将是预算拨款的增加或减少。
示例：一般估算为 10,000 美元，但由于要求模糊且项目可能很容易改变方向，因此有 +/- 30% 的价格调整选项。
这样，客户就可以大致了解预算内容，并且您可以灵活地对项目收费。
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.
这是一个非常棘手的问题。 看看 Robert Glass 在他的书“软件工程的事实与谬误”中对此主题有何评论”。 （请注意，亚马逊的新书价格低于二手书！[截至 2009-01-05 12:20 -08:00]；Google 图书上也有。）
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.)
如果您已成功向客户推销了敏捷方法并按小时计费，不要向他们估算完成项目所需的费用！。 即使他们说只是为了预算目的，也不要这样做！。
原因是任何成本估算都将被视为明确的承诺； 无论你多少次说不，以及客户多少次表示理解，这都会被视为承诺。 即使客户理解，他们的老板也不会理解，尽管他们无法合法地强迫您按照您所说的价格交货，但您将被认为是一家不兑现承诺的公司。 提供估算首先就失去了敏捷的所有优势。
我的建议是告诉他们，在财政年度结束之前（或您的客户感兴趣的任何其他计费周期），您的支出不会超过某某金额。 这应该足以让他们进行财务规划，而不必以任何方式表示该项目届时将完成。
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.
当我转点的时候，我只有满足以下两点才决定转点； 1) 找到并证明该转换的合理性并说服团队 2) 找到一种简单的方法来使用它。
令人信服
我花了很多时间阅读这个主题，但最终找到了说服我和我的团队的论点：几乎不可能找到两个程序员就一项任务所需的时间达成一致，但当显示两个不同的任务时，同样的两个程序员几乎总是会就哪个任务最大达成一致。
这是“估计”积压工作所需的唯一技能。 在这里，我使用了“估计”这个词，但在这个早期阶段，它更像是对待办事项进行从困难到简单的排序。
将分数放入待办事项列表
这一步是在整个 Scrum 团队的参与下完成的。
开始将故事逐一放入新的电子表格中，同时保持以下顺序：最大的故事位于顶部，最小的故事位于底部。 这样做，直到所有故事都在列表中。
现在是时候对这些故事进行阐述了。 我个人使用扑克规划量表 (1/2,1,2,3,5,8,13,20,40,100)，所以这就是我在本示例中使用的量表。 在该列表的底部，您可能会有微任务（需要 4 小时或更短时间完成的事情）。 给每个微任务1/2的值。 然后，通过为故事赋予值 1（等级中的下一个）继续列表，直到很明显故事要大得多（2 而不是 1，所以大两倍）。 现在使用值“2”，继续沿列表向上查找，直到找到显然应该有 3 而不是 2 的故事。继续此过程，一直到列表顶部。
注意：尽量将绝大多数点保持在 1 到 13 之间。第一次，您可能会有一堆大故事（20、40 和 100），您必须将它们分解成小于或等于 13 的块 这就是积分
和原始积压的内容。 如果您有一个新故事，请将其与该列表进行比较，看看它适合哪里（更大/更小的过程），并为其邻居赋予价值。
速度和速度 估计（宏观规划）
要估计完成积压工作需要多长时间，请进行第一个冲刺规划。 计算团队挑选的故事的总分，瞧！这就是你的第一个速度测量。 然后，您可以将待办事项中的总点数除以该速度，以了解需要多少次冲刺。
该速度会在前 2-3 个冲刺中发生变化并稳定下来，因此密切关注该值总是好的
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