在Scrum中，产品决策、流程引导和交付执行分别由Product Owner（产品负责人）、Scrum Master和开发团队承担。三者的边界可以概括为：Product Owner决定做什么、为什么做、先做哪个；Scrum Master保障协作规则被执行、障碍被清除；开发团队决定怎么做、做多少、如何达到完成标准。三者共同对Sprint目标负责，各自不越位替对方做决定。
要点总览（TL;DR）
- 产品决策由Product Owner承担，负责Product Backlog的内容、排序与验收方向；流程引导由Scrum Master承担，负责Scrum事件的引导、规则守护与障碍清除；交付执行由开发团队承担，自主决定任务拆分、技术方案与Sprint内可交付量。
- 边界核心是三类判断各归其位：Product Owner决定做什么、为什么做、先做哪个，Scrum Master保障怎么协作，开发团队决定怎么做、做多少，任何一方越位都会削弱Sprint目标的稳定性。
- 三类职责在Sprint Planning、每日协作、Sprint Review和Sprint Retrospective中交接，冲突按类型回到对应角色处理，无法在角色内解决时通过公开讨论形成共识。
- Scrum角色是职责定义而非行政职位，Product Owner不等于产品经理的全部工作，Scrum Master不等于项目经理，开发团队是跨职能交付单元；小团队可兼任，但切换角色时边界仍需清楚。
- 常见越位包括Scrum Master直接派活、Product Owner在站会逐人追问进度、开发团队自行更改优先级，共同原因是用单点控制替代了角色分工机制。
三类职责分别落在哪个Scrum角色上
Scrum只定义了三个角色，却要同时处理“方向对不对”“协作顺不顺”“交付稳不稳”三类问题。角色与职责的对应关系是理解Scrum分工的起点：每个角色都有明确的决策权和责任区，交叉地带通过事件和协商机制解决，而非靠某个人统一拍板。
| 职责类别 | 承担角色 | 核心问题 | 主要产出 |
|---|---|---|---|
| 产品决策 | Product Owner | 做什么、为什么做、先做哪个 | Product Backlog的内容与排序、Sprint目标的方向 |
| 流程引导 | Scrum Master | 怎么协作、规则是否被遵守、障碍是否被清除 | 有效的Scrum事件、可运行的流程、被移除的障碍 |
| 交付执行 | 开发团队 | 怎么做、做多少、如何达到完成标准 | 每个Sprint的可交付增量 |
三类职责共同指向Sprint目标。Product Owner确保目标有价值，Scrum Master确保团队能围绕目标顺畅协作，开发团队确保目标转化为可用的增量。任何一方缺位，Sprint目标都会落空：没有产品决策，团队做了不重要的事；没有流程引导，协作摩擦消耗交付能力；没有交付执行，决策和流程都停留在纸面。
产品决策的边界：Product Owner决定什么、不决定什么
Product Owner是产品价值的第一责任人，其决策权集中在Product Backlog上：决定哪些条目进入列表、以什么顺序排列、每个条目的描述是否清晰到可以开工。排序的依据是价值最大化，包括客户影响、业务收益、风险和时间窗口。在Sprint Review中，Product Owner主导验收方向的判断，决定增量是否符合预期、Backlog是否需要调整。
Product Owner的权限止于“做什么”和“为什么做”。技术实现方案由开发团队决定，Product Owner可以提出约束条件（如合规要求、性能预期），但不指定具体架构或实现路径。流程规则的解释与执行由Scrum Master负责，Product Owner不裁决Scrum事件如何开展。此外，Product Owner的决策需要建立在与开发团队和利益相关者的沟通之上：Backlog条目的细化通常需要开发团队参与澄清，排序调整也需要让相关方理解决策依据。单方面下达优先级而不解释原因，短期看似高效，长期会削弱团队对目标的认同。
流程引导的边界：Scrum Master管什么、不管什么
Scrum Master是Scrum规则的服务式引导者。其职责包括：确保团队和相关方理解Scrum的规则与目的，按计划组织并引导Sprint Planning、Daily Scrum、Sprint Review和Sprint Retrospective，帮助团队识别并清除阻碍交付的障碍，推动团队在回顾中形成可执行的改进项。对团队以外的组织，Scrum Master还承担Scrum辅导职责，帮助管理层和协作部门理解敏捷运作方式，减少外部干扰。
Scrum Master不承担产品优先级决策。Backlog排序出现分歧时，Scrum Master可以引导讨论、暴露分歧，最终决定权在Product Owner。Scrum Master也不代替开发团队分配任务或做技术判断：任务如何拆分、谁做什么、采用什么技术方案，属于开发团队的自主范围。Scrum Master的引导方式是提问、 facilitation和移除障碍，而非下指令。当流程规则与业务现实冲突时，Scrum Master的职责是让冲突被看见并推动团队找到适配方式，而非单方面修改规则或替团队做取舍。
交付执行的边界：开发团队自主决定什么
开发团队对“如何交付”拥有自主权。在Sprint Planning中，团队根据自身能力和对Backlog条目的理解，自组织地决定如何完成Sprint Backlog：任务如何拆分、内部如何分工、采用什么技术方案、以什么节奏推进。团队对Sprint内可承诺的交付量做出判断，这个判断基于历史速率和对当前条目的澄清程度，而非外部摊派。跨职能协作是交付执行的内在要求，设计、开发、测试等环节在团队内部协同，共同达到团队约定的完成定义。
开发团队的自主范围不包括变更Product Backlog的优先级。Sprint进行中若发现范围与目标冲突，例如新需求插入或原条目工作量远超预期，正确路径是回到Product Owner协商：由Product Owner判断是否调整Sprint目标、替换条目或缩小范围。团队自行更改优先级或悄悄扩大范围，会破坏Sprint目标的稳定性，也让产品决策失去依据。交付执行的边界可以概括为：团队决定“怎么做”和“做多少”，Product Owner决定“做什么”和“先做哪个”，两者在Sprint目标上对齐。
三类职责如何在同一机制中衔接
静态的职责划分只有在Sprint循环中运转起来才有意义。四个Scrum事件构成了三方交接的主要节点，每个节点都有明确的输入、产出和主导角色。
| 事件 | Product Owner | Scrum Master | 开发团队 |
|---|---|---|---|
| Sprint Planning | 说明Sprint目标与高优先级条目，参与澄清 | 引导会议，保障讨论聚焦 | 评估工作量，决定如何完成并承诺交付量 |
| 每日协作 | 按需澄清需求细节 | 观察协作状态，清除障碍 | 执行任务，同步进度与风险 |
| Sprint Review | 主导验收，判断增量是否符合预期，调整Backlog | 引导检视流程，记录反馈 | 展示增量，说明完成情况 |
| Sprint Retrospective | 参与并提供产品侧视角 | 引导回顾，推动改进项落地 | 检视协作方式，提出改进措施 |
在Sprint Planning中，三方输入汇合成一份可执行的Sprint Backlog：Product Owner带来排序后的条目和Sprint目标草案，开发团队带来容量评估和技术判断，Scrum Master保障讨论围绕目标展开并形成明确产出。每日协作中，开发团队推进任务，Scrum Master关注障碍是否被及时暴露和移除，Product Owner在需求细节上提供澄清。Sprint Review是产品决策的集中调整点，Product Owner根据增量表现和利益相关者反馈决定Backlog的下一步走向。Sprint Retrospective则由Scrum Master引导团队检视流程本身，改进项进入下一个Sprint的执行。
边界冲突时的处理路径取决于冲突类型：涉及优先级和价值判断的，回到Product Owner；涉及流程规则和协作方式的，由Scrum Master引导团队解决；涉及技术方案和工作分配的，由开发团队自主决定。冲突无法在角色内解决时，通过Sprint Review或Retrospective的公开讨论形成共识，而非私下越位处理。
当团队规模扩大、多个Sprint并行时，职责衔接需要可追溯的载体：需求池中的条目排序、Sprint Backlog的任务拆分、看板上的状态流转、评审记录的反馈。ONES的敏捷研发管理方案支持产品负责人按优先级将需求规划至对应迭代，并在迭代计划会议上与团队共同评审；团队达成一致后可用子任务拆分需求，迭代中通过敏捷看板管理任务状态、对齐进度与风险。这类工具承载的是职责衔接过程中的信息流转，角色分工本身仍由团队按Scrum规则约定。
与相邻概念的区别：角色、职责与职位
Scrum角色是职责定义，不是行政职位。一个人可以拥有某个职位头衔，但在Scrum中承担的角色取决于其实际职责。混淆角色与职位，是边界模糊的常见来源。
| Scrum角色 | 常见相邻概念 | 区别要点 |
|---|---|---|
| Product Owner | 产品经理 | Product Owner聚焦Backlog的价值排序与验收方向；产品经理岗位通常还包含市场调研、用户研究、商业化等更广的工作，这些工作不自动构成Scrum中的产品决策权 |
| Scrum Master | 项目经理 | Scrum Master引导流程、清除障碍、辅导Scrum实践，不承担进度摊派和资源调度；项目经理的职责范围通常包含计划、预算和跨项目协调 |
| 开发团队 | 只写代码的开发者 | 开发团队是跨职能的交付单元，包含设计、开发、测试等达到完成定义所需的技能，而非单一编码职能 |
在小团队中，三类职责可能由同一人兼任，例如产品负责人同时参与部分开发工作，或Scrum Master由团队成员轮值。兼任本身不违反Scrum，但边界仍需明确：同一个人在不同事务上切换角色时，要清楚当前行使的是哪类决策权。Product Owner兼任开发时，不能用自己的技术偏好替代团队的实现判断；Scrum Master兼任开发时，不能在引导回顾时同时为自己的任务辩护。边界清晰是兼任可行的前提。
具体例子与常见误解
以下场景展示了边界划分在实际工作中的运作方式，以及越位处理会带来什么问题。
- 需求插入Sprint：利益相关者在Sprint中途提出紧急需求。正确路径是提交给Product Owner，由Product Owner评估其价值与当前Sprint目标的冲突，决定是否替换条目、调整目标或排入下一个Sprint。开发团队不直接接收插入需求，Scrum Master不替Product Owner做取舍。
- Scrum Master直接派活：Scrum Master在站会后给成员分配任务，看似提高了效率，实际侵入了开发团队的自组织范围。任务分配应由团队内部协商完成，Scrum Master的角色是确保协商发生、障碍被记录。
- Product Owner在站会上逐人追问进度：每日站会是开发团队同步协作的场合，Product Owner可以旁听以了解进展，但逐人追问会把站会变成汇报会，削弱团队自主同步的意愿。进度信息应通过看板和团队自述获取。
- 开发团队自行更改优先级：团队在Sprint中觉得某个条目价值不高，自行调换顺序或搁置。这会让产品决策失去依据，也让利益相关者无法预期交付内容。正确做法是向Product Owner提出判断依据，由Product Owner决定是否调整。
这些误解的共同原因，是把引导、决策、执行混为一体：用行政效率替代角色分工，用单点控制替代机制运转。边界划分的价值不在于划清地盘，而在于让每类判断由掌握相应信息的人做出，并通过Sprint事件形成可检视的衔接。团队在实践中可以定期在回顾中检视三类职责是否被越位，把边界问题当作流程改进的一部分来处理。
常见问题
小团队里Product Owner、Scrum Master和开发团队由同一人兼任，边界还怎么划？
兼任本身不违反Scrum，关键在于同一个人切换事务时清楚自己当前行使的是哪类决策权。可以借助三个问题自检：这件事涉及Backlog排序和价值取舍吗，涉及就按Product Owner的方式处理并说明依据；涉及流程规则和协作方式吗，涉及就按Scrum Master的方式引导而非下指令；涉及技术方案和任务分配吗，涉及就交回团队协商。兼任时最容易出问题的是自己为自己的判断背书，例如Product Owner兼任开发时用技术偏好替代团队判断，或Scrum Master兼任开发时在回顾中为自己的任务辩护。团队可以在回顾中定期检视兼任场景下的越位情况，把边界问题当作流程改进的一部分。
Sprint进行中利益相关者直接找开发团队提需求，团队应该怎么处理？
正确路径是把需求转给Product Owner，由Product Owner评估其价值与当前Sprint目标的冲突，决定是否替换条目、调整Sprint目标或排入下一个Sprint。开发团队直接接收插入需求，会让产品决策失去依据，也让Sprint目标的稳定性被破坏。Scrum Master在这个过程中的职责是让冲突被看见，例如在每日协作中记录该需求对当前任务的影响，而不是替Product Owner做取舍。如果需求确实紧急，Product Owner与团队协商后调整范围，调整结果应在Sprint Review中向相关方说明。
Scrum Master不分配任务，那团队任务没人认领时该怎么办？
任务认领属于开发团队的自组织范围。Scrum Master可以做的是确保协商发生：在Sprint Planning或每日协作中指出有任务尚未被认领，请团队讨论如何安排，而不是直接点名派活。团队内部可以约定认领规则，例如按技能匹配、按负载均衡或自愿优先。若长期出现任务无人认领，通常反映的是Sprint Backlog拆分不够清晰、团队容量评估偏差或成员对目标认同不足，这些应在回顾中作为改进项处理，而非靠Scrum Master下指令解决。
Product Owner可以参加每日站会吗？参加时要注意什么？
可以参加。Product Owner旁听站会有助于了解进展和及时澄清需求细节。需要注意的是，每日站会是开发团队同步协作的场合，Product Owner逐人追问进度会把站会变成汇报会，削弱团队自主同步的意愿。更合适的做法是听团队自述，在需求细节被提及时提供澄清，进度信息通过看板和团队自述获取。如果Product Owner发现某条目理解有偏差，可以在站会后与相关人员单独沟通，避免占用团队同步时间。
三类职责在Sprint循环中衔接时，出现边界争议按什么顺序处理？
先按争议类型归类：涉及优先级和价值判断的，回到Product Owner；涉及流程规则和协作方式的，由Scrum Master引导团队解决；涉及技术方案和工作分配的，由开发团队自主决定。角色内无法解决时，把争议带到Sprint Review或Sprint Retrospective的公开讨论中形成共识，避免私下越位处理。争议处理后，可以在回顾中检视这类边界问题是否反复出现，若是，则考虑把处理规则写入团队的工作约定，减少下次判断成本。
