“经常交付工作软件，从几周到几个月，优先选择较短的时间范围。”
下一个原则强调使用迭代方法将项目分解为非常小的增量，称为冲刺或迭代，通常在两到四周的范围内。这很有道理的原因有两个：
- 所有敏捷开发过程（如scrum）都基于持续改进。我们希望团队采用一种经验的方法 (empirical approach) 来了解随着项目的进展，哪些是可行的，哪些是不可行的，并在必要时进行调整，而不是采用一个永不改变的严格定义的过程 (defined process)。如果将项目分解为很短的增量 (increments)，并且在每个增量结束时进行学习，那么学习和持续改进可以更快地发生。
一个流行的敏捷口头禅是:
“及早失败，经常失败”。 “Fail early, fail often.”
换句话说，在许多情况下，最好快速尝试一些东西，从中学习并做出调整，而不是花费所有可能需要的时间来尝试设计一种第一次毫无效果的方法。
- 人们工作效率更高，只需在短时间内完成任务。如果做得正确，团队会发展出一种节奏和节奏，这种节奏和节奏对于快速而有效地产生确定的工作量增量非常有效，就像制造装配线一样。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。