开发管理 CheckLists(12) -敏捷开发 SCRUM评估会议

本文主要是为了检测你对SCRUM 评估会议的了解和使用程度,

通过本文你可以检测一下

1、你们的SCRUM评估会议的过程和步骤

2、SCRUM评估的输出结果

一、会议目的

1.确定Backlog中各项的大小.

2.确定团队在一个Sprint中能够完成多少工作。

3.团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

4.修整Backlog内容:以合理方式分解Backlog各个项目,从而获得更深入的理解

基本要求:

只有团队才能作估算。ProductOwner(产品负责人)需要在场,以帮助判定某些用户故事能否拆分为更小的故事。

二、会议时间

1.该会议时间限制为不超过90分钟。

2.如果Sprint持续时间长于一周,那么每个Sprint举行两次估算会议比较合适

三、会议准备

1.邀请与会者:

产品负责人

ScrumMaster

团队所有成员

2.已按优先级排列好产品Backlog中的各项问题

3.把产品Backlog公开给所有人,保证其可被获取

4.在用作计划纸牌的一组卡片上写上标签1,2,3,5,8,13,21,34,89,并发到每个团队成员的手上

四、会议进程

介绍会议的目标

1.ProductOwner展示她希望得到估算的ProductBacklog条目。

2.团队使用规划扑克来估算Backlog条目。

3.如果完全还没开始着手对Backlog中的问题进行评估:

(1)、选择Backlog中您认为是最小用例的问题,并指派其工作量为2个StoryPoint对于产品Backlog中的各项问题:

(2)、由产品负责人来解释Backlog中该问题背后的详细用例。

(3)、团队各成员选出其手上的一张计划卡片,以投票决定他所认为的该问题的工作量大小。

(4)、所有团队成员同时亮出他们的卡片如果评估结果有分歧,让意见分歧最大的成员进行辩论,然后再次投票,直到所有人意见一致

(5)、评估结果被添加到Backlog项

4.如果某个Backlog条目过大,需要放到下一个或是后续的Sprint中,团队就会将该大Backlog条目划分为较小的几个Backlog条目,并对新的Backlog条目使用规划扑克进行估算。

5.重新估算Backlog中当前没有完成、但是可能会在接下来三个Sprint中要完成的条目。

6.通过简洁的总结来结束评估会议

(1)、如果有需要的话,再安排时间另开一个评估会议

7.区分出下一次估算会议需要澄清的Backlog条目。

五、会议结果

1.经过估算的ProductBacklog。

2.更小的Backlog条目。

3.需要澄清的问题。

      4. 公司的所有人员都要获得这个已经评估的backlog

开发管理 CheckLists(22) -组织项目资源

开发管理 CheckLists(21) -控制项目的范围

开发管理CheckLists(20)-项目利益相关者责任

开发管理CheckLists(19)-选择合适的团队成员

开发管理CheckLists(18)-敏捷开发ScrumMaster工作

开发管理CheckLists(17)-敏捷开发ScrumSprint回顾会议

开发管理CheckLists(16)-敏捷开发ScrumSprint评审会议

开发管理CheckLists(15)-敏捷开发Scrum每日例会

开发管理CheckLists(14)-敏捷开发ScrumSprint计划会议二

开发管理CheckLists(13)-敏捷开发ScrumSprint计划会议一

开发管理CheckLists(12)-敏捷开发SCRUM评估会议

开发管理CheckLists(11)-敏捷开发SCRUM全员会议

开发管理CheckLists(10)-敏捷开发框架SCRUM内容

开发管理CheckLists(9)-敏捷开发-故事验收测试

开发管理CheckLists(8)-敏捷开发-估算故事

开发管理CheckLists(7)-敏捷开发-编写故事

开发管理CheckLists(6)-敏捷开发-搜集故事

开发管理CheckLists(5)-风险检测表

开发管理CheckLists(4)-风险管理

开发管理CheckLists(3)-项目启动会议

开发管理CheckLists(2)-规划项目

开发管理 CheckLists(1) -启动项目

相关推荐