当团队对迭代进行承诺时，需要知道迭代的长度，以便按更好的节奏交付价值
迭代长度4~6周，得2分
迭代长度4周之内，得4分
过去三个迭代，迭代长度稳定在1个月，得5分
过去三个迭代，迭代长度稳定在4周，得6分
过去三个迭代，迭代长度稳定在3周，得8分
过去三个迭代，迭代长度稳定在2周之内，得10分
团队对测试共同负责，因此我们的迭代产品质量高，可以随时部署
团队在迭代中创建一些单元测试，得1分
团队在迭代中为每个故事创建单元测试，得1分
团队在迭代评审前测试每个故事，得2分
团队在编码后立刻测试每个故事，得2分
团队自动化每个新故事的功能测试，得2分
构建系统包，部署到stage或生产环境，并至少每24小时执行所有的自动化功能测试，得2分
只有当列表项符合DoR，团队才承诺，以便最快产生业务价值
迭代需求有文档，得1分
需求呈现为独立的、排好优先级的故事，得1分
故事以AIS格式，得2分
故事有外部可测试的验收标准，得2分
团队有书面的、真实执行的故事DoR，得2分
团队有书面的、真实执行的故事DoD，得2分
单一产品负责人帮助团队理解和排序价值，因此获得长期收益
单一PO对工作进行排序，得2分
PO只在Scrum会议时打扰团队，得2分
PO参加所有计划、梳理和评审会，及大部分站会，得2分
在迭代计划会前，PO创建好产品列表，并有团队对故事进行估算，得1分
PO知晓团队速率，并以此为基础维护发布路线图，得1分
PO鼓励团队减少技术债，得2分
列表按价值排序，因此我们能专注在能以最小成本产生最大商业价值的工作上
团队工作于多个排好序的列表，得1分
团队工作于单个排好序的列表，得2分
PO定期与团队讨论发布燃尽图，并基于历史速率调整列表优先级，得1分
三个月之后才做的故事以较大的颗粒度呈现，得1分
团队了解每个故事的投资回报率，得1分
PO根据净现值排列故事，得2分
PO优先安排低成本的原型以便尽快验证价值，得2分
团队估算远离统计偏差，干系人可以相信发布预测，并以此获利
团队在承诺之前先估算，得1分
PO，SM和非开发人员不参与估算，得1分
团队在估算前避免锚定偏差，得1分
团队或团队代表做估算，得1分
团队估算，得2分
团队用参考故事做估算，得2分
实际速率与估算速率偏差小于20%，得2分
团队知道迭代列表完成的趋势，因此团队成员可以聚力于高优先级的在制品
燃尽图呈现在团队看到的地方，得1分
团队每天回顾调整任务和燃尽图，得1分
团队以小时或点数做估算，或者保证每个任务大小差不多，得2分
只有整个任务完成，才体现在燃尽图上，得2分
不拆分任务，整个故事完成，才体现在故事燃尽图上，得2分
团队成员都知道历史速率，得1分
团队的承诺不超过速率，得1分
团队回顾进展，以便能持续提高生产率
团队至少每两个月举行回顾会，得2分
团队每个迭代后举行回顾会，得2分
回顾会仅限于团队和SM，选择性邀请PO和其他人，甚至排除SM，得2分
用报事贴或其他工具保证团队成员都参与，并跟进改善项，得2分
团队把最高改善项放在下个迭代的列表并且有验收标准，得2分
SM强化流程，移除障碍，创造透明度，使团队能专注工作
SM深刻理解敏捷和Scrum，得2分
SM不领迭代任务，得1分
SM强化团队共创的规则，得1分
SM及早发现和为团队排除障碍，得2分
SM维护一个排好序的障碍列表，得1分
SM使团队的进度对外透明，得2分
SM与团队、其他团队、经理、干系人、PO沟通良好，得1分
团队有效合作交付软件，以便把软件今早交给用户并快速调整
团队不算SM和PO 3到7人，得2分
团队成员认领任务，得2分
每个任务至少有两个人能独立完成，得2分
团队共同向迭代目标和列表承诺，得1分
团队共同克服障碍，得1分
团队在每个迭代减少技术债，得2分