Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master 组成。Scrum 团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum 团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。Scrum 团队（自身）已经证明， 对于所有之前所述 Scrum 的应用以及任何复杂工作来说，它都是越来越有效的。
Scrum 团队迭代增量式地交付产品，籍此最大化地获得反馈的机会。增量式交付“完成”的产品保证了一个可工作产品的潜在可用版本总是存在。
一、产品负责人PO
Product Owner角色定义
产品负责人的职责是将开发团队开发的产品价值最大化。确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资回报率ROI（profitability of product）负责。 是维护产品需求清单（ product backlog ）的人，代表利益相关者的利益。
Product Owner工作职责
负责最大化产品以及开发团队工作的价值。主要职责如下：
1、确定产品的功能；
2、决定发布的日期和发布内容；
3、为产品的ROI负责；
4、根据市场价值确定功能优先级；
5、每个sprint中，根据需要调整功能和优先级（每个sprint开始前调整）；
6、接受或拒绝开发团队的工作成果；
7、参与Scrum Planning Meetings（Sprint计划会议），Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）
产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
- 清晰地表述产品待办列表项；
- 对产品待办列表项进行排序，使其最好地实现目标和使命；
- 优化开发团队所执行工作的价值；
- 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；
- 确保开发团队对产品待办列表项有足够深的了解。
产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。
产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另一套需求开展工作。
一句话总结PO这个角色就是：告诉产品团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理。
二、Scrum Master
Scrum Master 对Scrum团队而言，他/她是一位服务型领导。Scrum Master帮助Scrum团队之外的人了解他/她如何与Scrum团队交互是有益的，通过改变他/她们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。
Scrum Master工作职责
确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下：
1、保证团队资源合理利用；
2、保证各个角色及职责良好协作；
3、解决团队开发中的障碍；
4、作为团队和团队外部的接口，协调解决沟通中的问题；
5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）。
Scrum Master 服务于产品负责人
Scrum Master以各种方式服务于产品负责人，包括：
- 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
- 找到有效管理产品待办列表的技巧；
- 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项
- 理解在经验主义的环境中的产品规划；
- 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
- 理解并实践敏捷性；
- 按要求或需要引导 Scrum 事件。
Scrum Master 服务于开发团队
Scrum Master 以各种方式服务于开发团队，包括：
- 在自组织和跨职能方面给予开发团队指导；
- 帮助开发团队创造高价值的产品；
- 移除开发团队工作进展中的障碍；
- 按要求或需要引导 Scrum 事件；
- 在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。
Scrum Master 服务于组织
Scrum Master 以各种方式服务于组织，包括：
- 带领并指导组织采纳 Scrum；
- 在组织范围内规划 Scrum 的实施；
- 帮助员工和利益攸关者理解并实施 Scrum 和经验产品开发；
- 引发能够提升 Scrum 团队生产率的改变；
- 与其他 Scrum Master 一起工作，增加组织中 Scrum。
SM应该在团队承担的几种角色：
1、引导者：
就像一个出租车司机，需要去哪儿，是由团队来决定的，作为引导者，带领团队到达他们想去的地方。引导团队建立团队规则，维护团队和指导团队外部成员遵守团队的规则。作为引导者需要特别注意的是，不能把自己的价值观强加于团队，让团队成员尽量表述自己的意见。
相信大众智慧---得到“最佳方案”
相信大众参与---得到“最佳执行力”
2、教练：
指导团队和PO遵循SCRUM的价值观。教练作为一面镜子，在每日立会和回顾会等会议上，只陈述事实，在日常工作中尽量多去收集一些数据，通过陈述事实和提问让团队去思考，通过这种方式让问题的解决达成一致。（如果当前的陈述让团队意识不到问题的存在，那么建议继续守望，继续收集数据，再陈述事实，通过反射让团队去发现问题）
3、移除团队障碍。
一句话总结SM这个角色就是：教整个团队怎么做，如何估时，跟进每天进度，风险控制，定期总结，计划排定。
三、Scrum Team
开发团队主要职责是执行冲刺，含每日检视和调整、梳理产品列表、冲刺规划、检视和调整产品与过程。开发团队包含各种专业人员，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。在Sprint评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。
开发团队的十大特征：
1）自组织--自下而上自发的组织，类似大雁飞行时候的人字型。没有外部的统治力量采用传统的自上而下、命令与控制的管理方式。
2）跨职能的多样化和全面化—可以给团队带来更多的视角和更好的效果。
3）T型技能—核心领域外的功能能力及职责、学科或者擅长。拥有深度和广度的技能。
4）火枪手的态度—人人为我，我为人人，就不会出现滥竽充数的人。 团队成员共同承担完成工作的责任，成败是整个团队的事情。
5）沟通广泛—尽量面对面沟通。
6）透明沟通—不要推三阻四，要坦诚、靠谱。
7）规模适中—5-7人比较合适。少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的 团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master 角色不包含在此数字中，除非 他们同时也参与执行 Sprint 待办列表中的工作。
8）专注和有责任感—同时做多个任务会降低生产力，要适度专注。
9）工作步调可持续—不要持续加班高强度，要达到工作的平衡。
10） 成员稳定—从长远而看，倾向于选择可以长期合作的成员来组成稳定的团队。一旦拥有高效能团队，就拥有了真正的资产。
鸡和猪的故事
一天，一只鸡散步时遇见了猪。
鸡对猪说:“嗨，我们合伙开个餐厅吧。”
猪说:“好啊，那准备取什么店名呢?”
鸡说:“要不，就叫火腿和鸡蛋吧。”
猪直接拒绝了:“那可不行。我要割肉，你只要下蛋。这样下去，我迟早要完蛋。”
这个故事实际上反映了软件开发过程中的2种不同角色，即需要完全投入的“猪”和只要部分投入的“鸡”。真实项目过程中，往往会发生这样的现象，领导喜欢临时往项目中新增任务，打乱原先的开发节奏，导致程序员压力倍增，士气低落，项目延期。
上文三个角色Product Owner, ScrumMaster, and Scrum Team就是“猪”的角色。
"鸡"角色
鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。
1、用户
软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”
2、利益所有者 (客户，提供商)
影响项目成功的人, 但只直接参与冲刺评审过程。
3、管理者
为产品开发团体架起环境的那个人
Scrum就是为了保护“猪”这种角色 （Product Owner, ScrumMaster, and Scrum Team），兼顾“鸡”的感受（用户、利益所有者 (客户，提供商)、管理者），从而确保整个项目正常交付。