agile iterations have fixed scope; the customer agrees to not change the scope during the iteration (though they can cancel the current iteration and start it over). In between iterations, the scope may change - dramatically.
given the above, scope creep by definition cannot occur in an agile project. The notion of scope creep is a legacy waterfall concept which assumes that the entire scope is known up front and will not change for the duration of the project. This concept does not apply to agile methods as long as each iteration has a fixed target.
This is quite simple in a scrum approach. In Scrum you set your sprint time, e.g. 2 weeks, and then fit items into this. When a client wants something added it gets put into the backlog and will be done in a future iteration. If they want it now you will have to explain to them that something will be dropped for that to fit into the iteration.
for me scope creep is happening when new function is added without the schedule being explicitly adjusted.
With agile methods the user is deeply involved in deciding which stories have priority for implementation. Hence the trades-off of one piece function against another are much clearer.
I wouldn't call it scope creep for the users to get the function they choose in the order they influence.
如果您的 PO 添加的功能不会给客户带来任何价值，那么这是最糟糕的范围蔓延 - 浪费！如果这些功能带来了价值，那就是敏捷。
Here's a simple heuristic, regardless of whether you're working on a month-long iteration, 1-2 weeks, or even a Kanban-like environment, where features are added in a continuous stream:
If your PO (or customer) adds features, but expects the deadline to stay the same - it's feature creep: If he changes the scope and his expectations accordingly, it may not be "Scrum" but it is agile.
If your PO adds features that do not bring any value to the customer, then it's scope-creep of the worst kind - waste! If the features bring value, it is being Agile.
1.) The extension of the scope of a project without increasing the payment/budget/time availableto the developers. This can happen in an agile process just us with any other process when the pm/scrum master or whatever doesn't stick to the figures and squeezes another feature into the project/iteration/sprint.
2.) the extension of the scope of a piece of software, beyond what it usefull. I think agile processes might actually help against this kind of problem, because the cost of a feature is very directly communicated to the project owner, so costs, should be very transparent. But the main tool against this kind of scope creep is the same everywhere: With every feature you have to check: do we really need it? Do we need it in this software? Or does it belong somewhere else? Or in management speak: what does it cost to build, what does it cost to maintain (often forgotten), how much does it increase revenue.
The answer to At what point do you tell the client that, 'No, we cannot do that change, because of ?' depends on the value of ?.
There's usually not a good reason to say "We cannot do this change." Some things you might say:
We can do this, but it'll mean X, Y and Z get dropped from the sprint goal.
We can do this, but it'll mean slipping the release schedule.
We can do this, but it will need additional testing.
We can do this, but first we need X hours of refactoring.
We can do this, but first we need to stabilize or revert in-progress feature X.
We can do this, but we could do X a lot faster and still deliver most of the same value.
We might be able to do this, but we need to task it out before we can estimate it.
We might be able to do this, but we need to spend X days doing a spike before we know for sure.
(1)-(5) just boil down to "Writing code takes time" -- with varying levels of detail. The (2)/(3) combo is probably the closest to the traditional idea of "scope creep." (In theory software developed by an agile team is always in a releasable state, but few teams are that good.) But scope creep is only a problem if it means the product owners making unrealistic demands on the development team. As long as the development team provides realistic estimates and the product owners accept them, dev shouldn't care how far the scope manages to creep.
If the development team has an unhealthy relationship with the product owner, and what you really mean is "Boy howdy is that dumb and I do not want to work on it," the usual response is to make the feature look really, really expensive.
Given that one of the main benefits of agile is the exchange of realistic estimates for realistic delivery dates, though, that's not a good place to be..
The most principle weakness of Agile is that most people who are doing "agile" really are flying by the seat of their pants. Things shouldn't change within a single iteration, but you should allow for change outside of that.
If the client is willing to pay, why should you say no? If there is only one client paying for it all, then he pretty much is in full power of what do develop ("if you don't do it, I will take my money and tell someone else to do it"). But of course, if the product has a large audience, then you need to have a well-defined focus of what the product should do, as adding unnecessary features may lower its usability.
Some situations come into my mind, when the development team might recommend the client to not implement some features. After that it's the client's responsibility, if he anyways wants to implement it. If the feature conflicts with some other, more important features, then it would be wise to not add it. If the feature does not give much value to the client, compared to the cost of implementing it, then it might not be smart to burn lots of money on it. Also in some cases it might make more sense to implement some features as a separate program, if their purpose is very much different from the original program - it's better to have many small applications that each do one thing and do it well, than one humongous application that does everything but is specialized on nothing.
Why should you say No? I don't know which flavor of agile development you're using. Scrum is the most prescriptive / has definite rules to cater to this scenario.
The PO (Product Owner) maintains the (things to do list) backlog. He decides which items go into the backlog and their priority. The PO is free to add more items to backlog at any point of time. He is not free however to change the sprint backlog (i.e the things the team has begun work on for the next couple of weeks)
In case of an emergency (some new knowledge), the PO can choose to abandon the sprint and start a new one with different backlog items.
Scope Creep shouldn't happen any more - unless you bend the rules. You have a truck that will carry 500 boxes (release plan), To add 100 boxes (new features) to the plan, the PO would have to first remove (descope) 100 least-wanted boxes from his original set.
发布评论
评论（9）
敏捷迭代有固定的范围； 客户同意在迭代期间不更改范围（尽管他们可以取消当前迭代并重新开始）。 在迭代之间，范围可能会发生巨大变化。
鉴于上述情况，根据定义，范围蔓延在敏捷项目中不可能发生。 范围蔓延的概念是一个遗留的瀑布概念，它假设整个范围是预先已知的，并且在项目持续时间内不会改变。 这个概念不适用于敏捷方法，只要每次迭代都有固定目标。
agile iterations have fixed scope; the customer agrees to not change the scope during the iteration (though they can cancel the current iteration and start it over). In between iterations, the scope may change - dramatically.
given the above, scope creep by definition cannot occur in an agile project. The notion of scope creep is a legacy waterfall concept which assumes that the entire scope is known up front and will not change for the duration of the project. This concept does not apply to agile methods as long as each iteration has a fixed target.
这在 Scrum 方法中非常简单。 在 Scrum 中，您可以设置冲刺时间，例如 2 周，然后将项目放入其中。 当客户想要添加某些内容时，它会被放入待办事项中，并将在未来的迭代中完成。 如果他们现在想要它，你就必须向他们解释，为了适应迭代，将会删除一些东西。
This is quite simple in a scrum approach. In Scrum you set your sprint time, e.g. 2 weeks, and then fit items into this. When a client wants something added it gets put into the backlog and will be done in a future iteration. If they want it now you will have to explain to them that something will be dropped for that to fit into the iteration.
对我来说，当添加新功能而没有明确调整时间表时，就会发生范围蔓延。
通过敏捷方法，用户可以深入参与决定哪些故事优先实施。 因此，一个功能与另一个功能的权衡就更加清晰。
我不会将其称为范围蔓延，让用户按照他们影响的顺序获得他们选择的功能。
for me scope creep is happening when new function is added without the schedule being explicitly adjusted.
With agile methods the user is deeply involved in deciding which stories have priority for implementation. Hence the trades-off of one piece function against another are much clearer.
I wouldn't call it scope creep for the users to get the function they choose in the order they influence.
这里有一个简单的启发式方法，无论您是在进行为期一个月的迭代、1-2 周的迭代，还是在类似看板的环境中工作，在该环境中，功能都会以连续的方式添加：
Here's a simple heuristic, regardless of whether you're working on a month-long iteration, 1-2 weeks, or even a Kanban-like environment, where features are added in a continuous stream:
我认为范围蔓延有两种：
1.）在不增加开发人员可用的付款/预算/时间的情况下扩展项目范围。 当 pm/scrum master 或其他任何人不遵守数字并将另一个功能压缩到项目/迭代/冲刺中时，这种情况可能会发生在敏捷流程中，就像我们和任何其他流程一样。
2.) 扩展软件的范围，超出其有用范围。 我认为敏捷流程实际上可能有助于解决此类问题，因为功能的成本非常直接地传达给项目所有者，因此成本应该非常透明。 但应对这种范围蔓延的主要工具在任何地方都是相同的：对于每一个功能，你都必须检查：我们真的需要它吗？ 我们在这个软件中需要它吗？ 或者它属于其他地方？ 或者用管理的话来说：建造成本是多少，维护成本是多少（经常被遗忘），它增加了多少收入。
I think there are two kinds of scope creep:
1.) The extension of the scope of a project without increasing the payment/budget/time availableto the developers. This can happen in an agile process just us with any other process when the pm/scrum master or whatever doesn't stick to the figures and squeezes another feature into the project/iteration/sprint.
2.) the extension of the scope of a piece of software, beyond what it usefull. I think agile processes might actually help against this kind of problem, because the cost of a feature is very directly communicated to the project owner, so costs, should be very transparent. But the main tool against this kind of scope creep is the same everywhere: With every feature you have to check: do we really need it? Do we need it in this software? Or does it belong somewhere else? Or in management speak: what does it cost to build, what does it cost to maintain (often forgotten), how much does it increase revenue.
您在什么时候告诉客户“不，我们不能进行更改，因为？”的答案取决于？的值。
通常没有充分的理由说“我们无法进行此更改”。 您可能会说：
(1)-(5) 归结为“编写代码需要时间”——详细程度各不相同。 (2)/(3) 组合可能最接近“范围蔓延”的传统理念。 （理论上，敏捷团队开发的软件总是处于可发布状态，但很少有团队能做到这一点。）但是，范围蔓延只有当产品负责人对开发团队提出不切实际的要求时才成为问题。 只要开发团队提供切合实际的估计并且产品所有者接受它们，开发人员就不应该关心范围会蔓延多远。
如果开发团队与产品所有者的关系不健康，而你真正的意思是“天哪，真是太蠢了，我不想做这个”，通常的反应是让该功能看起来非常非常昂贵。
鉴于敏捷的主要好处之一是交换实际交付日期的实际估计，但这并不是一个好地方。
The answer to At what point do you tell the client that, 'No, we cannot do that change, because of ?' depends on the value of ?.
There's usually not a good reason to say "We cannot do this change." Some things you might say:
(1)-(5) just boil down to "Writing code takes time" -- with varying levels of detail. The (2)/(3) combo is probably the closest to the traditional idea of "scope creep." (In theory software developed by an agile team is always in a releasable state, but few teams are that good.) But scope creep is only a problem if it means the product owners making unrealistic demands on the development team. As long as the development team provides realistic estimates and the product owners accept them, dev shouldn't care how far the scope manages to creep.
If the development team has an unhealthy relationship with the product owner, and what you really mean is "Boy howdy is that dumb and I do not want to work on it," the usual response is to make the feature look really, really expensive.
Given that one of the main benefits of agile is the exchange of realistic estimates for realistic delivery dates, though, that's not a good place to be..
敏捷最根本的弱点是，大多数进行“敏捷”的人实际上都是凭感觉行事。 事情不应在一次迭代内发生变化，但您应该允许在此之外进行更改。
The most principle weakness of Agile is that most people who are doing "agile" really are flying by the seat of their pants. Things shouldn't change within a single iteration, but you should allow for change outside of that.
如果客户愿意付钱，你为什么要拒绝呢？ 如果只有一个客户支付全部费用，那么他几乎完全有权开发什么（“如果你不做，我会拿走我的钱并告诉其他人去做”）。 但当然，如果产品拥有大量受众，那么您需要对产品应该做什么有一个明确的重点，因为添加不必要的功能可能会降低其可用性。
当开发团队可能建议客户不要实现某些功能时，我会想到一些情况。 之后，如果客户无论如何想实施的话，那就是客户的责任。 如果该功能与其他一些更重要的功能冲突，那么最好不要添加它。 如果与实施该功能的成本相比，该功能没有给客户带来太大价值，那么在其上投入大量资金可能并不明智。 此外，在某些情况下，如果某些功能的目的与原始程序有很大不同，那么将某些功能实现为单独的程序可能更有意义 - 最好有许多小型应用程序，每个应用程序只做一件事并做得很好，而不是一个庞大的应用程序可以做所有事情但不专门做任何事情的应用程序。
If the client is willing to pay, why should you say no? If there is only one client paying for it all, then he pretty much is in full power of what do develop ("if you don't do it, I will take my money and tell someone else to do it"). But of course, if the product has a large audience, then you need to have a well-defined focus of what the product should do, as adding unnecessary features may lower its usability.
Some situations come into my mind, when the development team might recommend the client to not implement some features. After that it's the client's responsibility, if he anyways wants to implement it. If the feature conflicts with some other, more important features, then it would be wise to not add it. If the feature does not give much value to the client, compared to the cost of implementing it, then it might not be smart to burn lots of money on it. Also in some cases it might make more sense to implement some features as a separate program, if their purpose is very much different from the original program - it's better to have many small applications that each do one thing and do it well, than one humongous application that does everything but is specialized on nothing.
你为什么要说“不”？ 我不知道您使用的是哪种敏捷开发风格。
Scrum 是最规范的/有明确的规则来迎合这种场景。
范围蔓延不应该再发生——除非你违反规则。 您有一辆卡车将运载 500 个箱子（发布计划），要向计划中添加 100 个箱子（新功能），采购订单必须首先从其原始集合中删除（缩小范围）100 个最不想要的箱子。
Why should you say No? I don't know which flavor of agile development you're using.
Scrum is the most prescriptive / has definite rules to cater to this scenario.
Scope Creep shouldn't happen any more - unless you bend the rules. You have a truck that will carry 500 boxes (release plan), To add 100 boxes (new features) to the plan, the PO would have to first remove (descope) 100 least-wanted boxes from his original set.