有可能影响、修正版本发布规划的事情包括：

    上个迭代中交付工作的实际速度。它比预计的是快还是慢？速度的变化会改变在项目剩余时间中的工作范围。
    现有故事和史诗在优先级方面的变化。
    由于项目环境发生的变化，导致需要引入新的故事和史诗。
    随着工作进行而显现出来的缺陷和技术债务【原注8】。
    风险识别完成后，出现了新的故事，或是已有故事发生改变。
    之前迭代中悬而未决的故事。
    非项目工作，降低了团队领取项目工作任务的能力。

迭代规划会议的首要任务，是要发现当前重要的故事和史诗，团队将会在当前迭代中针对它们开展工作。产品负责人会说明当前的优先级，还有发生改变的原因，确保整个团队对于优先级为什么要改变有明确认识。

当史诗和故事的列表重新排序完成，而且所有团队成员都已经了解了修正后的发布规划之后，团队会制定当前迭代中需完成工作的详细迭代规划。

团队会基于“昨天的天气”（很可能他们在当前迭代完成的工作量与上一个迭代相同，除非工作环境或是团队构成发生重大变化）和常识，估算自己能够在当前迭代中完成多少工作。然后团队会基于自己的工作交付能力，选择当前迭代要开发的工作。

选定故事和史诗之后，团队会把工作拆分成特定的任务，并分配给每个团队成员。理想状况下，任务分配会以“拉”的形式完成，团队成员根据自己的工作能力，选择自己要做的任务。任务应该非常小，从几个小时到1天不等，而且要是分散的、可度量的活动。迭代经理（Scrum中是Scrum Master）确定所有的工作任务都有人领取，而且会对承诺完成的工作做健全性检查（sanity check）：根据项目的环境现状，团队是否有能力交付他们承诺完成的任务？

当任务都被识别完成后，团队成员会对其排序和估算。估算现在基于完成某项任务需要的小时数。这些任务应该写在任务卡片上，并在故事墙上跟踪这些任务卡。

任务与故事连在一起，在故事墙上跟踪某个故事的状态迁移，要与其所包含任务的完成状况相联系。

迭代中的任务，包括为了完成故事需要完成的所有工作，还有为下个迭代的准备工作。

迭代Backlog列出了当前迭代中在故事墙上要跟踪的故事和史诗。

下面展示了一个任务列表的部分示例。

在迭代中，团队成员要根据任务来报告和跟踪他们的工作进度。这是他们个人每天做出的承诺。

燃尽图能够展示出初始的估算和迭代剩余的工作。每个任务实际花费的时间会得到跟踪，并用来帮助团队在下次迭代规划会议中的改进估算效果。

每日承诺

团队成员是在这时候监控他们的进度，并根据他们承诺要完成的任务报告进度。

在迭代内，每日立会是团队沟通进度的首要沟通工具。在项目的每个工作日里，团队聚在一起，并向彼此报告各自承诺要完成的任务进度状况。每日立会有一些简单的规则：

    它采取站立方式进行。
    长持续时间是15分钟。
    每个团队成员发言时间不超过1分钟。
    仅从用户故事和任务的层面报告进度。
    任务报告只有两种状态：完成或未完成。
    未完成任务要说明还需要几个小时/几个点数/多少工作量才能完成。
    阻止任务完成、或是项目进度的障碍要单独报告。
    每个团队成员都要回答以下3个问题：
        从上次会议开始，你完成了哪些工作？（要指明完成哪些任务，而不是如何度过你的）
        你将会在下次会议之前做哪些工作？
        哪些东西阻碍你的进度？（“没有问题”，意味着你能够交付自己当前的任务，而且符合估算的时间范围）
    如果遇到需要解决的问题，可以在每日立会之后处理。在每日立会之后进行一个简短的1对1会议解决特定问题，这是常用做法。
    迭代经理主要负责移除障碍，让团队充分发挥工作效率。

敏捷项目必须提供能够“安全失败”的环境，团队成员不会因为没有达成任务承诺遭受惩罚。大家要能够安全说出任务状态的真实情况，并且了解项目环境的现实情况。有时，我们的估算可能很糟糕（只是估算而已，又不是报价），又或者某些事情的发生让某些成员无法完成任务，整体环境必须让他们能够说出真实情况，这样团队成员能调整他们的日程表，将任务排序，并调整适应项目的现实。

当一个故事所有的任务都已经完成后，故事会移动到“完成”状态，而且这部分工作的故事点数会算到团队速度中。