For a given budget you know how much iterations can be done. The Product Owner should then prioritize the work to get the most value of the product backlog. This is how Agile works, fixed time and team size with variable scope (Agile is about scope management). And once the team velocity is known, you can forecast how much work (in points) can be done (# of sprints x velocity = size of the work that can be achieved).
Often, customer don't get it and wants "everything they think they need at a given time" (i.e. fixed scope). In this situation, you end up doing some kind of upfront analysis to brake down everything into small enough items to estimate them. Once this work has been done, you can forecast how much sprints you'll need by guessing on the velocity (# of sprints = total size / velocity). This is a very common situation for people with a waterfall background and will often lead to inaccurate end date (fixed scope and team size with variable time) because you can't really guess the velocity and the start of a project is the worst moment to do estimates.
In both cases, you'll need the velocity. The problem is that the velocity is actually 1) unknown before the team start to work and 2) will vary over time.
To solve 1), you could estimate guess the velocity as discussed in the second situation but this isn't very "Agile". Ideally, you should instead get the team start working to measure the actual velocity (which will be likely inaccurate during early iterations). An intermediary scenario is to give a first very rough estimate and to come back to the customer after a few iterations with a more precise one, once you've gathered more knowledge about the project and reduce the uncertainty.
To solve 2), I track measured velocity over time and use the highest and lowest velocity and the average velocity of the last 3 sprints as work hypothesis. This allows me to do optimistic, pessimistic and realistic forecasts (respectively).
Absolutely, in scrum you fix cost and time. Then you let the features vary. So you can tell the customer it will be done on XX/XX/XXXX at a cost of $YYY.YY. It is up to them to then prioritize the features they want to ensure the most important ones get done under those constraints.
Yes and No. I believe that Scrum is a great approach in getting the owner involved in the planning of the sprints.
So in the case of estimation, it would be difficult to say "we'll get the project done in 30 days". Instead, the owner will have an expectation on what will get done say in the first and second given week, and a perception of what will get done in 30 days.
In my opinion, this is more valuable than giving an estimate of 30 days and then being lucky, or way off the mark.
Also, you'll have a WAY better estimation of what will be done in the near future. Another great thing about Scrum is that you can tailor your deployment to possible alter or remove items to have a more usable product after 30 days, than potentially something completely unusable using waterfall.
You can promise that a n-week sprint takes exactly n weeks and m sprints take n*m weeks. Therefore schedule estimation is easy. Cost/effort estimation is also easy, given a certain team size and project duration. What you cannot reliably promise is what features eventually get delivered and what don't.
There are four main control variables for a project: scope, cost/effort, schedule, quality. You can choose which variables are the drivers (i.e. fixed) for your project and which are not. You cannot have them all as drivers at the same time at least one variable needs to be kept free to allow for balancing the project.
With traditional waterfall you have fixed scope (the spec) and usually a fixed schedule (target date). You can balance the project by increasing cost/effort (e.g. adding more people, working overtime) or taking shortcuts in quality. These balancing factors do not behave linearly and you get problems in other areas if you push them too far.
With agile including Scrum you have fixed schedule (iterations or sprints) and fixed quality level (definition of done). Cost/effort is proportional to how many people you have in the team. Scope is the main balancing factor. It has the nice property of behaving quite linearly: increases or decreases in scope do not cause hugely non-linear changes in the other drivers. The key to success is feature prioritization to get the maximum value out of the scope you can deliver.
发布评论
评论（6）
对于给定的预算，您知道可以完成多少次迭代。然后，产品负责人应该优先考虑工作，以获得产品待办事项的最大价值。这就是敏捷的工作方式，固定的时间和团队规模，但范围可变（敏捷是关于范围管理）。一旦团队速度已知，您就可以预测可以完成多少工作（以点为单位）（冲刺数量 x 速度 = 可以完成的工作量）。
通常，客户不会得到它，并且想要“他们认为在给定时间需要的一切”（即固定范围）。在这种情况下，您最终会进行某种预先分析，将所有内容分解为足够小的项目来估计它们。完成这项工作后，您可以通过猜测速度来预测需要多少冲刺（冲刺数量=总大小/速度）。对于具有瀑布背景的人来说，这是一种非常常见的情况，并且通常会导致结束日期不准确（固定范围和团队规模，时间可变），因为您无法真正猜测速度，并且项目的开始是最糟糕的时刻。做估计。
在这两种情况下，您都需要速度。问题在于，速度实际上是 1) 在团队开始工作之前未知，2) 会随着时间的推移而变化。
为了解决 1)，您可以
估计猜测第二种情况中讨论的速度，但这不是很“敏捷”。理想情况下，您应该让团队开始测量实际速度（在早期迭代期间可能不准确）。中间方案是给出第一个非常粗略的估计，并在收集了有关项目的更多知识并减少不确定性后，在几次迭代后以更精确的估计返回给客户。为了解决 2) 问题，我跟踪一段时间内测量的速度，并使用最近 3 次冲刺的最高和最低速度以及平均速度作为工作假设。这使我能够（分别）做出乐观、悲观和现实的预测。
For a given budget you know how much iterations can be done. The Product Owner should then prioritize the work to get the most value of the product backlog. This is how Agile works, fixed time and team size with variable scope (Agile is about scope management). And once the team velocity is known, you can forecast how much work (in points) can be done (# of sprints x velocity = size of the work that can be achieved).
Often, customer don't get it and wants "everything they think they need at a given time" (i.e. fixed scope). In this situation, you end up doing some kind of upfront analysis to brake down everything into small enough items to estimate them. Once this work has been done, you can forecast how much sprints you'll need by guessing on the velocity (# of sprints = total size / velocity). This is a very common situation for people with a waterfall background and will often lead to inaccurate end date (fixed scope and team size with variable time) because you can't really guess the velocity and the start of a project is the worst moment to do estimates.
In both cases, you'll need the velocity. The problem is that the velocity is actually 1) unknown before the team start to work and 2) will vary over time.
To solve 1), you could
estimateguess the velocity as discussed in the second situation but this isn't very "Agile". Ideally, you should instead get the team start working to measure the actual velocity (which will be likely inaccurate during early iterations). An intermediary scenario is to give a first very rough estimate and to come back to the customer after a few iterations with a more precise one, once you've gathered more knowledge about the project and reduce the uncertainty.To solve 2), I track measured velocity over time and use the highest and lowest velocity and the average velocity of the last 3 sprints as work hypothesis. This allows me to do optimistic, pessimistic and realistic forecasts (respectively).
是的，您可以（并且确实）评估 Scrum 项目。 [注意“Scrum”是一个英文单词，不是首字母缩写词或缩写词。它不应该全部大写。]
您可以通过这种方式估算 Scrum 项目。
写下待办事项。
将积压工作分解为冲刺。
按从最有价值到最不有价值的顺序对冲刺进行优先级排序。
按
向客户提供冲刺优先列表。
他们可以随时停止工作，因为每个冲刺都是有用的，而第一个冲刺是系统中最有用和最重要的部分。
这就是估计。这是他们的事来管理。
Yes, you can (and do) estimate Scrum projects. [Note "Scrum" is an English word, not an acronym or abbereviation. It should not be in all-capitals.]
You estimate a Scrum project this way.
Write down the backlog.
Break the backlog into sprints.
Prioritize the sprints from most valuable to least valuable.
Provide this prioritized list of sprints to the customer.
They are free to stop work at any time, since each sprint is useful and the first sprint is the most useful and important part of the system.
That's the estimate. It's theirs to manage.
当然，在 Scrum 中你可以确定成本和时间。然后你让特征发生变化。因此，您可以告诉客户它将在 XX/XX/XXXX 完成，费用为 $YYY.YY。然后由他们来确定他们想要的功能的优先级，以确保最重要的功能在这些限制下完成。
Absolutely, in scrum you fix cost and time. Then you let the features vary. So you can tell the customer it will be done on XX/XX/XXXX at a cost of $YYY.YY. It is up to them to then prioritize the features they want to ensure the most important ones get done under those constraints.
是和否。我相信 Scrum 是让所有者参与冲刺规划的好方法。
所以在估算的情况下，很难说“我们会在30天内完成这个项目”。相反，所有者将对第一周和第二周内要完成的工作有一个预期，并对 30 天内要完成的工作有一个看法。
在我看来，这比给出 30 天的估计然后运气好或偏离目标更有价值。
此外，您将对不久的将来要做什么有更好的估计。 Scrum 的另一个伟大之处在于，您可以定制部署以更改或删除可能的项目，以便在 30 天后获得更可用的产品，而不是使用瀑布可能完全无法使用的产品。
Yes and No. I believe that Scrum is a great approach in getting the owner involved in the planning of the sprints.
So in the case of estimation, it would be difficult to say "we'll get the project done in 30 days". Instead, the owner will have an expectation on what will get done say in the first and second given week, and a perception of what will get done in 30 days.
In my opinion, this is more valuable than giving an estimate of 30 days and then being lucky, or way off the mark.
Also, you'll have a WAY better estimation of what will be done in the near future. Another great thing about Scrum is that you can tailor your deployment to possible alter or remove items to have a more usable product after 30 days, than potentially something completely unusable using waterfall.
这取决于您想要预测什么。
您可以保证一个 n 周的冲刺正好需要 n 周，而 m 个冲刺需要 n*m 周。因此，日程估算很容易。考虑到一定的团队规模和项目持续时间，成本/工作量估算也很容易。您无法可靠地承诺哪些功能最终会交付，哪些功能不会交付。
项目有四个主要控制变量：范围、成本/工作量、进度、质量。您可以选择哪些变量是项目的驱动程序（即固定变量），哪些不是。您不能同时将它们全部用作驱动程序，至少需要保留一个变量以平衡项目。
对于传统的瀑布，您有固定的范围（规范）并且通常有固定的时间表（目标日期）。您可以通过增加成本/工作量（例如增加人员、加班）或在质量方面采取捷径来平衡项目。这些平衡因素并不是线性表现的，如果你把它们推得太远，你就会在其他领域遇到问题。
通过包括 Scrum 在内的敏捷，您可以拥有固定的时间表（迭代或冲刺）和固定的质量水平（完成的定义）。成本/工作量与团队中有多少人成正比。范围是主要的平衡因素。它具有表现相当线性的良好特性：范围的增加或减少不会导致其他驱动程序发生巨大的非线性变化。成功的关键是确定功能优先级，以在您可以提供的范围内获得最大价值。
It depends on what you want to predict.
You can promise that a n-week sprint takes exactly n weeks and m sprints take n*m weeks. Therefore schedule estimation is easy. Cost/effort estimation is also easy, given a certain team size and project duration. What you cannot reliably promise is what features eventually get delivered and what don't.
There are four main control variables for a project: scope, cost/effort, schedule, quality. You can choose which variables are the drivers (i.e. fixed) for your project and which are not. You cannot have them all as drivers at the same time at least one variable needs to be kept free to allow for balancing the project.
With traditional waterfall you have fixed scope (the spec) and usually a fixed schedule (target date). You can balance the project by increasing cost/effort (e.g. adding more people, working overtime) or taking shortcuts in quality. These balancing factors do not behave linearly and you get problems in other areas if you push them too far.
With agile including Scrum you have fixed schedule (iterations or sprints) and fixed quality level (definition of done). Cost/effort is proportional to how many people you have in the team. Scope is the main balancing factor. It has the nice property of behaving quite linearly: increases or decreases in scope do not cause hugely non-linear changes in the other drivers. The key to success is feature prioritization to get the maximum value out of the scope you can deliver.
正如 Steve McConnell 在软件估算中所说，每当您需要提供估算时：
“专家判断”或计算是最后的资源。尝试计算真实事物和/或参考历史数据计算一个有意义的数字。
无论您使用哪种方法，无论是 Scrum 还是其他方法，这都适用。
As Steve McConnell says in Software Estimation, whenever you need to provide an estimate:
"Expert judging" or reckoning is a last resource. Try counting real things and/or referring to historical data to compute a meaningful figure.
This is applicable regardless of the method you use, be it Scrum or whatever else.