承诺(commitement)是Scrum所强调的核心价值观之一。也是执行Scrum时的关键概念。
有人认为，在缺少开明管理的情况下，团队的承诺将只是一种大的、自我强加的指挥棒，在每次团队未满足目标时敲打他们。还有人认为团队会走各种捷径来履行承诺，可能在必要时降低质量。
但是，一个人作出并满足自己承诺的能力，和过去一样，仍是一种专业素质。
如果在实施我们的新模型时有管理成熟度的问题，那么应该纠正它。如果有团队削弱质量边角的问题，团队应该自我修正，以便定义可以满足并且保持质量的目标。
甚至更重要的是，我们将以团队满足其迭代承诺的能力，作为机构针对近期发布目标的实现能力的重要构建块，见后面章节的论述。那么我们就可以设想，这样做对于企业是多么的关键。
在Sprint计划会议时，团队将被要求作出本次迭代的承诺。实际操作中团队对Sprint范围作出承诺有许多方式：
基于速率的承诺
有些团队只是按照优先顺序(根据定序、依赖等进行了调整)把故事拉入迭代待办事项，然后在估值到达其目标速率时停止。这是一种粗线条方式，因为团队只知道“那是正确的工作量”，但是没有针对可用资源、任务分解和指派做进一步研究。在这种模型中，团队依靠其经验、持续交流、对故事的搭配，并且在必要时“彼此掩护对方的背后”，因为有些故事可能使部分成员过载。
所以，这种承诺只是在迭代待办事项中的一组故事。许多团队还对每个故事指定一名主工程师，其任务是负责相关故事直到完成，独立出他们对特定故事的独特角色。采取这种方式，使每个故事都有一名负责人，其工作是了解状态、消除阻碍，并且更一般地说，他们辅助完成相关故事的工作。
基于目标的承诺
有些团队已经在一起工作了一段时间，他们基于一些与产品负责人协商的宽泛目标作出承诺。在这一模型中，故事本身只是通向结尾的一种方式，而目标的叙述则胜过一切。在此之后，有些团队采取拉/看板风格的方式，他们把条目从待办事项中抽出并顺序地完成它们。很少的(如果有)故事可能被提前承诺，团队只是直接开始工作，把故事从待办事项拉出，在需要时创建新的故事，热烈交流，并且试图“直接”完成迭代目标。
基于任务的承诺
在更细的粒度层次上，许多XP和Scrum团队采取严格的基于任务的承诺。特别是XP，倾向于以细粒度细节分派故事。在这种情况下，每个故事被分解为一些任务，由团队的成员个体承担起这些任务。
任务有相应的负责人(承担任务的人员)，并且以小时(而不是点)估算。在燃尽图(burndown chart)上，对已执行的任务小时和剩余任务小时作对比，描述一种形式的迭代状态。正如在模型中一对多关系表明，即使为了交付一个小故事，也经常需要多个任务。
当团队采取基于任务的承诺模型时，达成迭代承诺的过程如下：
1. 从待办事项取出顶级故事；
2. 把它分解为一些任务；
3. 个人承担任务的职责并且估算小时；
4. 重复，直到耗尽团队的小时。
然后由团队对相关故事以及那些故事所隐含的目标作出承诺。
在基于任务的承诺方式中，个人责任包括：完成任务、当任务完成或受阻时与他人交流，以及无须监督地继续到下一项任务。这样的方式是高度颗粒化的，有高度的问责性。如果所有任务都已完成，则相关故事可以被验收，并且迭代的目标将得到满足。
