参考资料：https://www.uperform.cn/uperform-principle-for-good-user-story-and_ready-product-backlog/
Scrum团队
Scrum三大角色，合起来称为Scrum团队。
在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）, Scrum Master(SM)和交付团队(DT)。
我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的交付团队，对应到龙舟赛的划桨团队，团队必须协调一致，作为一个整体前进，在这样的环境下单打独斗，各自为政没有任何胜算。
打造自组织团队的三个约定
- 完成的定义 Definition of Done (DoD)
当产品代办事项列表条目或者增量被描述为“完成”的时候,每个人都必须理解“完成”意味着什么。虽然这在不同的 Scrum 团队之间会有巨大的差别,但是团队成员必须对完成工作意味着什么有相同的理解,这样才能保证透明性。这就是 Scrum 团队的“完成” 定义,用来评估产品增量在什么时候完成，并且没有妥协质量。
DoD这个定义是团队对产品负责人的承诺，是团队当前能力的体现。可以用来指导开发团队了解在 Sprint 计划会议的时候他们能选择多少产品代办事项列表条目。每个 Sprint 的目标都是交付遵循 Scrum 团队当前的“完成的定义”的潜在可交付产品增量。
开发团队在每个 Sprint 交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。每个增量都附加于之前所有增量并经过充分测试,以此保证所有的增量都能工作。
随着 Scrum 团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。
需要注意的是，如果在每个迭代，我们对“完成”的标准要求过低，那么这会导致在每个迭代，我们都会遗留一些完成外的工作，完成外的工作持续累计会增加项目的风险，有可能导致产品负责人决定发布的时候，产品却因为累积了过多的完成外的工作而无法发布，以致于我们还需要一个额外的Sprint来使它稳定。
- 准备好的定义 Definition of Ready (DoR)
当PO拿出Product Backlog请团队拉动工作时，团队是否能否立刻开始，抑或充满疑惑，似懂非懂？有些戏精工程师就在迭代根据自己的理解胡乱做，待到验收的时候产品负责人和客户大叫“这不是我要的！”
于是DoR这个定义（也称“就绪的定义”）正式产品负责人对团队的承诺，是团队能够开工的保证。团队有权利要求PO提供这个检查清单中的必需内容，不然的话就先不开始这个工作。
DoR一般包括：每个PBI和用户故事应当具备背景和目标、足够理解的信息、已估算、已排序、已记录下验收条件测试用例，界面原型草图，乃至浏览器兼容性列表等等。
- 团队工作约定 Team Working Agreement
也称团队纪律。自组织团队中每个人如何协作配合？就像乔布斯在《The Lost Video》中提到的，打造团队就是要明确目标，然后建立一个容器，让大家互相争吵、碰撞、打磨，于是丑陋的石头也会变成漂亮的石头。
大家之间磨合的约定和规则是符合现实的，外人不能也无法给出一个传统的流程强迫大家遵循，一定是大家提出、大家认可，大家才能执行下去。
这些工作约定可以显式化张贴出来，也允许更改。比如每个迭代回顾会的时候，SM可以引导大家对Working Agreement进行更新。一般内容中包括：开站会时间、用什么工具IDE、持续集成轮流负责、讨论时不准玩手机、一次只有一个话题、先不评判别人的想法等等。
