其中一个 关键敏捷原则 关于 确定时间表和变化范围.
在DSDM（动态系统开发方法）中，这些迭代称为“时间框”；在Scrum中 敏捷管理实践将它们称为Sprint。
对于常规业务（BAU）更改为 现有 产品，一个Sprint可能等于该产品的发布。但是对于项目来说’在功能对用户具有足够的价值值得发布之前，将需要多个Sprint。
就项目而言，’显然必须有某种发布计划 坐在各个Sprint上。评估在准备发布产品之前可能需要多少个Sprint至关重要。
在完成了此发行计划并确定了需要多少Sprint之后，可能一开始就进行了一些较高的估算，以确保获得项目资金，因此不能单独运行单个Sprint。
如果存在危险，那就是任何悬垂物–或者我个人更喜欢称呼它 宿醉- 在项目结束时积累并产生弓浪效应，在某些项目中’更像是海啸！
虽然范围可能会有所不同，并且在敏捷开发中应该有所不同，但是当您简单地可以’在不严重破坏原始业务案例基础的情况下，可以进一步更改范围。不幸的是’s at that point you’回到很好的老式滑点，在许多使用任何方法论的软件开发项目中，这种滑倒都是太普遍了，也太痛苦了。
那么BAU呢？您肯定可以在BAU中运行各个Sprint，每个Sprint都会导致产品发布吗？是的，从技术上讲您可以。 但是我说你不应该’t.
只是为了澄清–是的，您当然可以运行单独的Sprint，每个Sprint都会导致产品发布。但理想情况下，您不应该’即使在BAU场景中，也要完全隔离地运行一系列Sprint。
产品所有者，产品团队以及负责产品商业成果的人员应理想地形成各种总体规划；如果可以的话，可以制定高水平的路线图。这对于作为业务计划，预算，收入预测等的基础非常重要。即使在这个级别上计划是不科学的，也必须对产品的主要推动因素有清晰的业务愿景，并且该愿景需要告知Sprint的优先级。
凯莉
也可以看看：
10 Key Principles of 敏捷 Development
时间不等人！
我如何确定我的项目将按时交付？
