Scrum敏捷项目管理知识样本

SCRUM敏捷管理知识
一、什么是scrum
Scrum是一种用于开发和维持复杂产品框架，是一种增量、迭代开发过程。

在这个框架中，整个开发过程由若干个短迭代周期构成，一种短迭代周期称为一种Sprint，每个Sprint 建议长度是2到4周(互联网产品研发可以使用1周Sprint)。

在Scrum中，使用产品Backlog 来管理产品需求，产品backlog是一种按照商业价值排序需求列表，列表条目体现形式普通为顾客故事。

Scrum团队总是先开发对客户具备较高价值需求。

在Sprint中，Scrum团队从产品Backlog中挑选最高优先级需求进行开发。

挑选需求在Sprint筹划会议上通过讨论、分析和估算得到相应任务列表，咱们称它为Sprintbacklog。

在每个迭代结束时，Scrum团队将递交潜在可交付产品增量。

Scrum来源于软件开发项目，但它合用于任何复杂或是创新性项目。

Scrum流程如下图：
SCRUM框架涉及3个角色、3个工件、5个活动、5个价值，详细阐明如下：
3个角色
1.产品负责人（ProductOwner）
2.ScrumMaster
3.Scrum团队
3个工件
1.产品Backlog（ProductBacklog）
2.SprintBacklog
3.产品增量（Increment）
5个活动
1.产品Backlog梳理睬议（ProductBacklogRefinement）
2.Sprint筹划会议（SprintPlanningMeeting）
3.每日站会（DailyScrumMeeting）
4.Sprint评审会议（SprintReviewMeeting）
5.Sprint回顾会议（SprintRetrospectiveMeeting）
5个价值
1.承诺–乐意对目的做出承诺
2.专注–把你心思和能力都用到你承诺工作上去
3.开放–Scrum把项目中一切开放给每个人看
4.尊重–每个人均有她独特背景和经验
5.勇气–有勇气做出承诺，履行承诺，接受别人尊重
SCRUM理论基本
Scrum以经验性过程控制理论（经验主义）做为理论基本过程。

经验主义主张知识源于经验,以及基于已知东西做决定。

Scrum采用迭代、增量办法来优化可预见性并控制风险。

Scrum三大支柱支撑起每个经验性过程控制实现:透明性、检查和适应。

Scrum三大支柱如下：第一：透明性（Transparency）
透明度是指，在软件开发过程各个环节保持高度可见性，影响交付成果各个方面对于参加交付所有人、管理生产成果人保持透明。

管理生产成果人不但要可以看到过程这些方面，并且必要理解她们看到内容。

也就是说，当某个人在检查一种过程，并确信某一种任务已经完毕时，这个完毕必要等同于她们对完毕定义。

第二：检查（Inspection）
开发过程中各方面必要做到足够频繁地检查，保证可以及时发现过程中重大偏差。

在拟定检查频率时，需要考虑到检查会引起所有过程发生变化。

当规定检查频率超过了过程检查所能容许限度，那么就会浮现问题。

幸运是，软件开发并不会浮现这种状况。

另一种因素就是检查工作成果人员技能水平和积极性。

第三：适应（Adaptation）
如果检查人员检查时候发现过程中一种或各种方面不满足验收原则，并且最后产品是不合格，那么便需要对过程或是材料进行调节。

调节工作必要尽快实行，以减少进一步偏差。

Scrum中通过三个活动进行检查和适应：每日例会检查Sprint目的进展，做出调节，从而优化次日工作价值；Sprint评审和筹划会议检查发布目的进展，做出调节，从而优化下一种Sprint工作价值；Sprint回顾会议是用来回顾已经完毕Sprint，并且拟定做出什么样改进可以使接下来Sprint更加高效、更加令人满意，并且工作更高兴。

二、 SCRUM术语
Scrum：Scrum无相应中文翻译
Agile：敏捷
Lean：精益
Iterative：迭代式
Iteration：迭代
AgileManifesto：敏捷宣言
Empirical：经验性
EmpiricalProcess：经验性过程
Transparency：透明性
InspectandAdapt：检视与调节
Sprint：原意为冲刺，Scrum中Sprint无相应中文翻译，指一种迭代
SprintGoal：Sprint目的
ProductOwner：产品负责人简称PO
ScrumMaster：简称SM,普通不翻译
DevelopmentTeam：Scrum开发团队
ScrumTeam：指PO,SM和开发团队
ScrumRoles：Scrum角色，指PO,SM和开发团队
Emergent：涌现
ProductBacklog：产品待办列表，指需求清单
SprintBacklog：Sprint待办列表，指Sprint任务清单
SprintBurn-downChart：Sprint燃尽图，团队用于做Sprint内进展跟踪ReleaseBurn-downChart:发布燃尽图，产品负责人做发布进展跟踪SprintPlanningMeeting:Sprint筹划会议
DailyScrumMeeting：每日站会
SprintReviewMeeting：Sprint评审会议SprintRetrospectiveMeeting:Sprint回顾会议ProductBacklogRefinement:产品待办列表梳理
ProductBacklogItem:产品待办清单条目，简称PBI
UserStory:顾客故事，指一条需求
StoryPoint：衡量顾客故事工作量大小计量单位
Velocity:团队速度
SprintTask:实现一条需求需要做一种技术任务
DefinitionofDone:DoD，完毕定义
Stakeholders：干系人
Backlog：待办列表
Artifact：工件
Estimation：估算
Collaboration：协作
ScalingScrum：大规模Scrum
三、 SCRUM来源
Scrum原始含义
Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。

争球双方各有8个队员参加，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其她前锋队员分别站在背面，后排队员用肩顶住前锋队员臀部，构成3、2、3或3、4、1
阵形。

然后，由犯规队对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有助于本队。

当球抛入通道时，前排3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必要等待前锋将球踢回后，方可移动。

1986Scrum这个词汇初次应用于产品开发
1986年，竹内弘高和野中郁次郎在NewNewProductDevelopmentGame文章初次提到将Scrum 应用与产品开发，她们指出：
老式“接力式”开发模式已经不能满足迅速灵活市场需求，而整体或“橄榄球式”办法——团队作为一种整体迈进，在团队内部传球并保持迈进，这也允许以更好满足当前激烈市场竞争。

1993年JeffSutherland初次将Scrum用于软件开发
敏捷思想深受日本工业界最佳实践影响，特别是丰田和本田公司履行精益原则，以及竹内弘高和野中郁次郎开发知识管理方略。

受到以上思想影响，以及对世界范畴内软件项目研究，JeffSutherland在1993年初次在Easel公司定义了用于了软件开发行业Scrum流程，并开始实行。

1995年JeffSutherland和KenSchwaber规范化了Scrum框架，并在OOPSLA95上公开发布。

敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷办法。

，KenSchwaber和MikeBeedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

KenSchwaber和MikeCohn共同开办了Scrum联盟。

四、经验性过程
软件开发是一种复杂活动，在软件产品开发过程中不但存在着需求不拟定性，也存在着技术不拟定性，再加上参加软件开发主体普通是由多人构成软件开发团队，加上人因素，就让整个软件开发活动变得非常复杂。

如下图所示，软件开发活动普通处在下图很复杂区域。

图-01
为了管理软件开发活动，咱们会引入过程控制来管理它。

过程控制普通有两种方式，第一种方式是预定义过程，第二种方式是经验性过程。

咱们所熟知是预定义过程，它普通是使用已知办法解决已知问题。

制造业生产线就是典型预定义过程，例如生产饼干、啤酒、汽车生产线等。

预定义过程特点是予以固定输入，得到固
定输出，过程可重复。

它优势在于可以大规模批量生产。

预定义过程缺陷在于一旦过程定义浮现错误，或产品设计上存在瑕疵，会导致比较大损失。

图－02
如果咱们盼望解决问题比较复杂，并且存在着较大不拟定性时候，咱们需要使用经验性过程。

经验性过程特点是过程是不可以完全预先定义好，成果是不可预知，生产过程是不可重复。

例如研究一项新技术，下一盘棋，踢一场球赛，在过程运营当中，咱们需要通过不断获得真实反馈，然后进行适应和调节，使得过程可以产出咱们需要成果。

“在过程运营机制相称简朴易懂状况下，典型做法是采用预定义建模方式。

如果过程复杂限度超过预定义方式能力范畴，便应用经验性方式。

”
——B.A.OgunnaikeandW.H.Ray
《过程动态学、建模与控制》软件产品研发普通存在多诸多不拟定性，并且生产过程非常复杂，因此更适合使用经验性过程来管理。

Scrum以经验性过程控制理论做为理论基本过程。

Scrum采用迭代、增量办法来优化可预见性并控制风险。

Scrum过程框架基石涉及如下三个方面：
第一：透明性（Transparency）
透明度是指，在软件开发过程各个环节保持高度可见性，影响交付成果各个方面对于参加交付所有人、管理生产成果人保持透明。

管理生产成果人不但要可以看到过程这些方面，并且必要理解她们看到内容。

也就是说，当某个人在检查一种过程，并确信某一种任务已经完毕时，这个完毕必要等同于她们对完毕定义。

第二：检查（Inspection）
开发过程中各方面必要做到足够频繁地检查，保证可以及时发现过程中重大偏差。

在拟定检查频率时，需要考虑到检查会引起所有过程发生变化。

当规定检查频率超过了过程检查所能容许限度，那么就会浮现问题。

幸运是，软件开发并不会浮现这种状况。

另一种因素就是检查工作成果人员技能水平和积极性。

第三：适应（Adaptation）
如果检查人员检查时候发现过程中一种或各种方面不满足验收原则，并且最后产品是不合格，那么便需要对过程或是材料进行调节。

调节工作必要尽快实行，以减少进一步偏差。

Scrum中通过三个活动进行检查和适应：每日例会检查Sprint目的进展，做出调节，从而优化次日工作价值；Sprint评审和筹划会议检查发布目的进展，做出调节，从而优化下一种Sprint工作价值；Sprint回顾会议是用来回顾已经完毕Sprint，并且拟定做出什么样改进可以使接下来Sprint更加高效、更加令人满意，并且工作更高兴。

五、 SCRUM团队三个角色
Scrum团队中涉及三个角色，她们分别是产品负责人、开发团队和ScrumMaster。

Scrum团队是自组织、跨职能完整团队。

自组织团队决定如何最佳地完毕她们工作,而不是由团队外其她人来指挥她们。

跨职能团队拥有完毕工作所需要所有技能,不需要依赖团队外部人。

Scrum团队模式目是最大限度地优化适应性、创造性和生产力。

Scrum团队通过迭代和增量交付产品功能办法最大化反馈机会。

增量交付潜在可交付产品增量保证了每个迭代均有潜在可发布版本。

Scrum角色之：产品负责人
产品负责人负责最大化产品以及开发团队工作价值。

实现这一点方式会随着组织、Scrum团队以及单个团队成员不同而不同。

产品负责人是管理产品待办事项列表唯一负责人。

产品待办事项列表管理涉及: •清晰地表达产品代办事项列表条目
•对产品代办事项列表中条目进行排序,最佳地实现目的和使命
•保证开发团队所执行工作价值
•保证产品代办事项列表对所有人可见、透明、清晰,并且显示Scrum团队下一步工作•保证开发团队对产品代办事项列表中条目达到一定限度理解
产品负责人可以亲自完毕上述工作,也可以让开发团队来完毕。

然而,产品负责人是负责任者。

产品负责人是一种人,而不是一种委员会。

产品负责人也许会在产品代办事项列表中体现一种委员会需求,但要想变化某条目优先级必要先说服产品负责人。

为保证产品负责人工作获得成功,组织中所有人员都必要尊重她决定。

产品负责人所作决定在产品待办事项列表内容和排序中要清晰可见。

任何人都不得规定开发团队按照另一套需求开展工作,开发团队也不容许听从任何其她人指令。

Scrum角色之：开发团队
开发团队包括了专业人员,负责在每个Sprint结尾交付潜在可发布“完毕”产品增量。

只有开发团队成员才干创造增量。

开发团队由组织构建并授权,来组织和管理她们工作。

所产生协同工作能最大化开发团队整体效率和效力。

开发团队有如下几种特点:
•她们是自组织,没有人(虽然是ScrumMaster都不可以)告诉开发团队如何把产品代办事项列表变成潜在可发布功能。

•开发团队是跨职能,团队作为一种整体拥有创造产品增量所需要所有技能。

•Scrum不承认开发团队成员头衔,无论承担哪种工作她们都是开发者。

此规则无一例外。

•开发团队中每个成员可以有特长和专注领域,但是责任归属于整个开发团队
•开发团队不包括如测试或业务分析等负责特定领域子团队。

开发团队规模
开发团队最佳规模是小到足以保持敏捷性,大到足以完毕重要工作。

少于3人开发团队没有足够交互,因而所获得生产力增长也不会很大。

小团队在Sprint中也许会受到技能限制,从而导致无法交付可发布产品增量。

不不大于9人团队需要过多协调沟通工作。

大型团队会产生太多复杂性,不便于经验过程管理。

产品负责人和ScrumMaster角色不包括在此数字中,除非她们也参加执行Sprint代表事项列表中工作。

Scrum角色之：ScrumMaster
ScrumMaster负责保证Scrum被理解并实行。

为了达到这个目,ScrumMaster要保证Scrum 团队遵循Scrum理论、实践和规则。

ScrumMaster是Scrum团队中服务式领导。

ScrumMaster协助Scrum团队外人员理解她们如何与Scrum团队交互是有益。

ScrumMaster 通过变化这些交互来最大化Scrum团队所创造价值。

ScrumMaster服务于产品负责人
ScrumMaster以各种方式服务于产品负责人,涉及:
•找到有效管理产品代办事项列表技巧
•清晰地和开发团队沟通愿景、目的和产品代表事项列表条目
•辅导开发团队创立清晰简要产品代表事项列表条目
•在经验主义环境中理解长期产品规划
•理解并实践敏捷
•按需推动Scrum活动
ScrumMaster服务于开发团队
ScrumMaster以各种方式服务于开发团队,涉及:
•指引开发团队自组织和跨职能
•辅导并领导开发团队创造高价值产品
•移除开发团队进展过程中障碍
•按需推动Scrum活动
•在Scrum尚未完全被采纳和理解组织环境下指引开发团队
ScrumMaster服务于组织
ScrumMaster以各种方式服务于组织,涉及:
•领导并指引组织采用Scrum
•在组织范畴内筹划Scrum实行
•协助员工及干系人理解并实行Scrum和经验性产品开发
•发起能提高Scrum团队生产力变革
•与其她ScrumMaster一起工作,协助组织更有效应用Scrum
六、 SCRUM三个工件
Scrum工件以不同方式呈现工作和价值,可以用来提供透明性以及检查和适应机会。

Scrum 中所定义工件能最大化核心信息透明性,来保证Scrum团队成功地交付完毕增量。

ProductBacklog–产品待办事项列表
产品待办事项列表是一种排序列表,包括所有产品需要东西,也是产品需求变动唯一来源。

产品负责人负责产品待办事项列表内容、可用性和优先级。

产品待办事项列表是一种持续完善清单,最初版本只列出最初始和众所周知需求。

产品待办事项列表依照产品和开发环境变化而演进。

待办事项列表是动态,它经常发生变化以辨认使产品合理、有竞争力和有用所必须东西。

只要产品存在,产品待办事项列表就存在。

产品待办事项列表列出了所有特性、功能、需求、改进办法和缺陷修复等对将来发布产品进行变化。

产品待办事项列表条目包括描述、顺序和估算特性。

产品待办事项列表普通以价值、风险、优先级和必要性排序。

它是一种按照优先级由高到低排列一种序列，每个条目有唯一顺序。

排在顶部产品待办事项列表条目需要及时进行开发。

排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值意见越一致。

排序越高产品待办事项列表条目比排序低更清晰、更详细。

依照更清晰内容和更详尽信息就能做出更精确估算。

优先级越低,细节信息越少。

开发团队在接下来Sprint中将要进行开发产品待办事项列表条目是细粒度,已经被分解过,因而,任何一种条目在Sprint时间盒内都可以被“完毕”。

开发团队在一种Sprint中可以“完毕”产品待办事项列表条目被以为是“准备好”或者“可执行”,能在Sprint筹划会议中被选取。

随着产品使用、价值获取以及市场反馈,产品待办事项列表变成了更大、更详尽列表。

由于需求永远不会停止变化,因此产品待办事项列表是个不断更新工件。

业务需求、市场形势和技术变化都会引起产品待办事项列表变化。

若干个Scrum团队经常会一起开发某个产品。

但描述下一步产品开发工作产品待办事项列表只能有一种。

那么这就需要使用对产品待办事项列表条目进行分组属性。

通过产品Backlog地梳理来增添细节、估算和排序。

这是一种持续不断过程,产品负责人和开发团队协作讨论产品代表事项列表条目细节。

在产品待办事项列表梳理时候,条目会被评审和修改。

然而,产品负责人可以随时更新产品代办事项列表条目或酌情决定。

梳理在Sprint中是一项兼职活动,在产品负责人和开发团队之间展开。

普通,开发团队有自行优化领域知识。

然而,何时如何完毕优化是Scrum团队决定。

优化普通占用不超过开发团队10%时间。

开发团队负责所有估算工作。

产品负责人可以通过协助团队权衡取舍来影响她们决定。

但是,最后估算是由执行工作人来决定。

监控向目的迈进进度
在任何时间,达到目的剩余工作量是可以被合计。

产品负责人至少在每个Sprint评审时候追踪剩余工作总量。

产品负责人把这个数量与之前Sprint评审时剩余工作量做比较,来评估在但愿时间点完毕预测工作达到目的进度。

这份信息对所有干系人都透明。

Scrum不考虑已经花在产品代办事项列表条目上工作时间。

咱们只关怀剩余工作和日期这两个变量。

各种趋势燃尽图、燃烧图和其她筹划实践都能用来预测进度。

它们已经被证明有用。

然而,这并不能代替经验主义重要性。

在复杂环境下,将要发生东西是未知,只有已经发生事情才干用来做前瞻式决策。

SPRINTBACKLOG
Sprint代办事项列表是一组为当前Sprint选出产品代办事项列表条目,外加交付产品增量和实现Sprint目的筹划。

Sprint代办事项列表是开发团队对于哪些功能要包括在下个增量中,以及交付那些功能所需工作预测。

Sprint代办事项列表定义了开发团队把产品代办事项列表条目转换成“完毕”增量所需要执行工作。

Sprint代办事项列表使开发团队拟定、达到Sprint目的所需工作清晰可见。

Sprint代办事项列表是一份足够详细筹划,使得进度上变化能在每日例会中得到理解。

开发团队在整个Sprint中都会修改Sprint代办事项列表,Sprint代办事项列表也会在Sprint 进程中慢慢显现,例如开发团队按照筹划工作并对完毕Sprint目的所需工作有更多理解。

当浮现新工作时,开发团队需要将其追加到Sprint待办事项列表中去。

随着任务进行或者被完毕,需要更新每项任务估算剩余工作量。

如果筹划中某个某些失去开发意义,就可以将其除去。

在Sprint内只有开发团队可以对Sprint待办事项列表进行修改。

Sprint待办事项列表是高度可见,是对团队筹划在当前Sprint内完毕工作实时反映,并且,该列表只属于开发团队。

ProductBacklog功能点被放到Sprint固定周期中，SprintBacklog会由于如下因素发生变化:
1.随着时间变化，开发团队对于需求有了更好理解，有也许发现需要增长某些新任务到SprintBacklog中。

2.程序缺陷做为新任务加进来，这个都做为承诺提交任务中未完毕工作。

ProductOwner也许会和Scrumteam一起工作，以协助team更好理解Sprint目的，ScrumMaster和team也许会觉得小调节不会影响sprint进度，但会给客户带来更多商业价值。

监控Sprint进度
在Sprint中任意时间点,Sprint待办事项列表所有剩余工作总和都可以被计算。

开发团队至少在每日例会时追踪所有剩余工作。

开发团队每天追踪剩余总和并预测达到Sprint目的也许性。

通过在Sprint中不断追踪剩余工作,开发团队可以管理自己进度。

Scrum不考虑已经花在Sprint待办事项列表上工作时间。

咱们只关怀剩余工作和日期这两个变量。

燃尽图（BURN-DOWNCHART)
Sprint燃尽图（SprintBurn-downChart)
SprintBurndownChart显示了Sprint中累积剩余工作量，它是一种反映工作量完毕状况趋势图。

图中Y轴代表是剩余工作量，X轴代表是Sprint工作日。

在Sprint开始时候，ScrumTeam会标示和预计在这个Sprint需要完毕详细任务。

所有这个Sprint中需要完毕，但没有完毕任务工作量是累积工作量，团队会依照进展状况每天更新累积工作量，如果在Sprint结束时，累积工作量减少到0，Sprint就成功结束。

由于在Sprint刚开始时候，增长任务工作量也许不不大于完毕任务工作量，因此燃尽图有也许略微呈上升趋势。

发布燃尽图（ReleaseBurn-downChart）
在Scrum项目中，团队通过每个Sprint结束时更新发布燃尽图来跟踪整个发布筹划进展。

发布燃尽图记录了在一段时间内产品Backlog总剩余估算工作量变化趋势。

X轴代表项目周
期，以Sprint为单位，Y轴代表是剩余工作量，普通以顾客故事点、抱负人天或者team-days 为单位。

七、 SCRUM五个活动
Scrum活动:产品待办事项列表梳理
产品待办事项普通会很大,也很宽泛,并且想法会变来变去、优先级也会变化,因此产品待办事项列表梳理是一种贯穿整个Scrum项目始终活动。

该活动包括但不限于如下内容: •保持产品待办事项列表有序
•把看起来不再重要事项移除或者降级
•增长或提高涌现出来或变得更重要事项
•将事项分解成更小事项
•将事项归并为更大事项
•对事项进行估算
产品待办事项列表梳理一种最大好处是为即将到来几种Sprint做准备。

为此,梳理时会特别关注那些即将被实现事项。

需要考虑不少因素,这涉及但不限于如下内容:
抱负状况下,下一种Sprint备选事项都应当提高“商业价值”。

开发团队需要可以在一种Sprint内完毕每一种事项。

每个人都需要清晰预期产出是什么。

产品开发决定了,有也许需要其他技能和输入。

因而,产品待办事项列表梳理最佳是所有团队成员都参加活动,而不单单是产品负责人。

Scrum活动：Sprint筹划会议
每个Sprint都以Sprint筹划会议作为开始，这是一种固定期长会议，在这个会议中,Scrum 团队共同选取和理解在即将到来Sprint中要完毕工作。

整个团队都要参加Sprint筹划会议。

针对排好序产品待办事项列表(Product Backlog),产品负责人和开发团队成员讨论每个事项,并对该事项达到共识,涉及依照当前“完毕定义”,为了完毕该事项所需要完毕所有事情。

所有Scrum会议都是限定期。

Sprint筹划会议推荐时是Sprint中每周相应两⼩时或者更少(译者注:例如,一种Sprint包括2个星期,则
Sprint筹划会议时长应为4个小时或者更少)。

由于会议是限制时长,Sprint筹划会议成功⼗分依赖于产品待办事项列表质量。

这就是产品待办事项列表梳理十分重要因素。

在Scrum中,Sprint筹划会议有两某些:
1.决定在Sprint中需要完毕哪些工作
2.决定这些工作如何完毕
第一某些:需要完毕哪些工作?
在会议第一某些,产品负责人向开发团队简介排好序产品待办事项,整个Scrum团队共同理解这些工作。

Sprint中需要完毕产品待办事项数目完全由开发团队决定。

为了决定做多少,开发团队需要考虑当前产品增量状态,团队过去工作状况,团队当前生产能力,以及排好序产品待办事项列表。

做多少工作只能由开发团队决定。

产品负责人或任何其他人,都不能给开发团队强加更多工作量。

普通Sprint均有个目的,称作Sprint目的。

这将十分有效地协助人们更加专注于需要完毕工作本质,而不必花太多精力去关注那些对于咱们需要完毕工作并不重要⼩小细节。

第二某些:如何完毕工作?
在会议第二某些⾥里,开发团队需要依照当前“完毕定义”一起决定如何实现下一种产品增量。

她们进⾏行⾜足够设计和筹划,从而有信心可以在Sprint中完毕所有工作。

头几天工作会被分解成⼩小单元,每个工作单元不超过一天。

之后要完毕工作可以稍⼤大些,后来再对它们进⾏行分解。

决定如何完毕工作是开发团队职责,决定做什么则是产品负责人职责。

在筹划会议第二某些,产品负责人可以继续留下来回答问题,以及澄清某些误解。

不论如何,团队应当很容易找到产品负责人。

Sprint筹划会议产出 Sprint筹划会议最后需要Scrum团队对Sprint需要完毕工作数量和复杂度达到共识,并预期在一种合理条件范畴内完毕它们。

开发团队预测并共同承诺她们要。