在项目管理的传统方法中，团队会在项目开始前确定并同意项目范围。这些需求一旦转化为成本和时间估算，就会变得固定。同时，也会提前约定日期。这种情况下，需要在前期进行大量的分析和探索，试图在完全了解之前就学习和决定所有事情。在实践中，这种前期的探索需要时间。无论产品交付团队是否真的在产品上工作，这种在“模糊”前端所花费的时间都会加到最终交付日期上。定义和估算交付范围所需的所有工作需要很多时间。实际上，这个待办事项列表只会帮助确定项目或产品何时“完成”，而这对于客户或销售人员来说本身并没有意义。很容易忽视这种试图在前期固定和定义所有工作的全职成本，特别是因为从事这项工作的人通常可以不“计算”这段时间作为交付的一部分。
标准方法：瀑布模型包装下的敏捷 由于范围是固定的，实际上需要一个压力释放阀，通常是左侧三个三角形中的一个：时间、质量和成本。然后，花费数月时间跟踪项目进度，并且与客户互动有限（因为还没有“完成”），这又是另一种浪费的时间。 有一种方法可以显著减少这种浪费，那就是尽早引入客户，并在高度纪律化的结构中最大化学习。在敏捷方法中，采取了完全相反的方法。不试图在前期固定范围；固定了参与规则，以允许业务和技术团队成员在进行过程中优先考虑范围。
相反，严格定义了项目的业务和技术标准，而没有完全同意范围是什么。因此，同意将花费高达185,000美元，通过自动化测试确保质量，并且有3个月的时间交付一些可以销售的东西。可能只交付一个功能，但如果它是一个有价值的功能，那么客户就会为此付费。如果所有这些都是明确的，那么产品团队本身可以根据从客户那里学到的东西，从操作上优先考虑范围。对于所有类型的产品，最终客户和市场将决定购买正在构建的东西。
更早开始工作，更频繁地发货，并尽早纳入客户反馈 这里有什么根本不同？ 范围由产品团队的一系列操作或战术决策定义，而不是由外部定义的战略决策。 高级业务利益相关者不需要了解产品中的技术细节以及项目的一部分“完成”。这涉及到太多细节，并且传达了对精心招聘和培训的高薪技术专家团队的判断缺乏信任。这也破坏了团队对结果的所有权感。因为他们的工作的所有方面都是外部定义的，只是被扔给他们。
// 示例代码：敏捷开发中的用户故事
class UserStory {
constructor(id, title, description) {
this.id = id;
this.title = title;
this.description = description;
}
}
// 创建一个用户故事
let story = new UserStory(1, "用户注册", "用户应该能够创建一个账户。");