第一步:产品负责人陈述Sprint目标,讲用户故事
' \0 n b0 l) e/ j- V
产品负责人讲解他/她提议的Sprint目标,以及他/她希望被纳入Sprint的用户故事。如果其中有些用户故事在上一个Sprint的Backlog梳理活动中已经讲解过,那么在这个步骤中可以省略,产品负责人只需要给团队明确这个Sprint要做哪些用户故事即可。
% J0 a$ b6 d" ^7 L; X
很多产品负责人不知道怎么讲用户故事。有的产品负责人把用户故事的标题念一遍,或者干脆把故事卡摊到桌上说:“就这些,你们看看有什么问题。” ( Z$ g, s( Z# Q |$ G9 P9 J; }+ E
产品负责人要讲清楚用户故事,需要讲以下内容。 * v( W1 k! ]6 Y% \" u3 D
- Who:用户是什么角色。
- What:完成什么活动。
- Why:达成什么目的。
- How:具体怎么做。如果有业务流程图、线框图、参考规范或标准等,也需要给团队介绍。
- 验收条件:做到什么程度算完成。
' m1 Z; q8 y: x9 L9 Z
/ \) R: ]: y' x+ W z1 G1 O5 J( ~
第二步:产品负责人澄清产品需求 " J0 P( S; W8 E. n/ d9 L" U% |
产品负责人就Sprint目标以及每个用户故事做现场解答,确保团队每个人对用户故事都有一致的理解。在这个过程中,一般会对用户故事进行细化,有可能还会拆分出新的用户故事。 {3 c" O7 ~" Z* @' p+ p
第三步:团队估算完成用户故事所需时间
. l0 i8 c$ X& Y# ]3 ~1 J
在估算过程中,产品负责人会发现,有的故事貌似大家都有共同的理解,但其实没有。因此,产品负责人要对用户故事做进一步澄清,而大的故事会继续拆分,需要的话会重新估算时间。 0 k6 r( P4 J! R9 O
第四步:团队选取SprintBacklog,调整Sprint目标
, y+ z, Y, s( v
团队依据历史Sprint速率,以及对完成用户故事所需时间的估算,按照产品Backlog的优先级,选取用户故事,作为这个Sprint的Backlog。
: a8 }: F: F) L; D! v1 z
依据选取的SprintBacklog,团队审视产品负责人提议的Sprint目标是否可以达成。如果SprintBacklog的范围超过了Sprint目标,团队应该与产品负责人协商,是否应该调整Sprint目标。 . f% Z9 _4 l0 a' Q- I
在Tommy团队的一个Sprint计划会议上,产品负责人David提议的Sprint目标是:用户能够完成下订单和支付的采购过程。 . ^# g8 m! Y% d' x7 d
团队估算SprintBacklog后发现,与支付有关的用户故事没有富余时间,不能放到这个Sprint里做。于是,团队与产品负责人商议,将Sprint目标更改为:用户完成下单过程,支持货到付款,下个Sprint再做支付的流程。
/ M3 j6 ]& S n) Z; e& ` m
第五步:拆分任务
/ F$ E; {% {3 q
接下来,团队就每一个用户故事拆分出具休的任务。每个任务的粒度争取在一天之内。 * V9 a5 k8 D; H- d
Tommy的团队在这个Sprint计划中有这样一个用户故事:购物者想把一个商品加到购物车里。 + @4 F' E9 ]8 P
团队讨论,为了完成这个用户故事,需要完成以下任务。
2 ^ _7 t! M# i/ T- X
- 修改后台数据库,预计5小时。
- 添加购物车UX设计,预计2小时。
- 前台页面JS开发,预计4小时。
- 写自动化验收测试脚本,预计3小时。
- 更新购物者帮助说明,预计2小时。) ]$ Y0 m8 }4 {0 J- s1 g
+ |7 @* e: M& _9 x* ^7 ?
团队用卡片将每个用户故事和任务写下来,为方便互动,大家围着卡片讨论。卡片展开后如图6-10所示。 + U W* G* I- \0 Q) T: H1 W5 B$ j
图6-10Sprint计划任务拆分示例图
. o# D3 _1 k) I! F" P
4 p: @2 f" y. b6 a4 d4 C# y
新的Scrum团队一开始拆分出的任务通常都比较大,比如10天、8天、5天的任务。而任务最好在一天之内完成,因为任务越大,其中蕴藏的风险可能越多。团队在探讨如何把任务拆小的过程中,会暴露出实现用户故事的风险。
/ ^9 \2 S! {- R( u1 A) C5 w& D+ I
当团队形成将任务拆小的习惯后,又容易走向另一个极端:经常出现1小时或半小时的任务。比如,开发弹出消息对话框需要0.5小时。 6 {8 Q0 r" G5 v/ N
如果有一堆过小粒度的任务,会额外增加管理成本,也是不提倡的。一天之内的粒度是最合适的。
2 Z8 g0 O9 j* a. q! J! K. A% W
第六步:判断SprintBacklog是否达到产能上限
; ^! m1 m! p) d8 ?
Tommy团队在这个Sprint估算的任务工时之和为150小时(如图6-10所示),而在Sprint计划前的工作(输入3:团队做SprintBacklog的可用时间)中,团队做SprintBacklog的可用时间只有142小时,Tommy问大家:“这可怎么办呢?”
- O3 P: [2 B$ o3 P$ Y% |& Z% k+ W7 E! Z
团队说:“才超出了8个小时,没准能做完。”
2 J) Z/ y" E2 @2 {
这个时候,作为ScrumMaster的Tommy问道:“大家确定可以吗?真的愿意挑战一下吗?为什么觉得可以做完呢?”
, @' R; j, d. e9 P5 c- F
不管团队是否愿意挑战,我们应该尊重团队的决定。如果团队不想挑战,那么需要从Backlog里取下一个或几个用户故事。
9 v4 n+ }9 Y; m" d, w1 I' w4 c
第七步:承诺目标
7 A+ D7 t# K! |* k* |# }. ]7 o/ W
终于到了最后一步。在Sprint计划结束前,ScrumMaster需要问大家对这个Sprint是否有信心,从而确保每个成员为达成Sprint目标做出承诺。 & K. c1 G) s4 _% n4 O
很多团队都省略了承诺目标这一步,ScrumMaster也没有确认大家的信心和承诺就结束了Sprint计划会议,团队直接进入开发。从大部分工程师的习惯来看,即使有人没有信心也不会说的,因为这会显得整个团队好像就他一个人没有信心。而往往他看到的风险可能是其他人没有想到的。 / j0 \% K! n/ a5 X [
一种高效征求意见的方法是用五指拳(FistofFive)投票,如图6-11所示。 4 K0 r" N+ [/ E# h! ]6 c( P
' \9 a. g6 u" h* h2 c! ]! ^1 e
图6-11五指拳投 五指拳投票法的具体含义如下。
9 _7 i0 J' n- l5 q* e& L
- 5个手指:完全有信心,闭着眼睛都可以达到!
- 4个手指:有信心,不出意外的话可以达到!
- 3个手指:有点信心,但需要努力!
- 2个手指:没有信心,很难达到!
- 1个手指:不可能实现,我宁愿回家睡觉!/ y1 B1 B2 \" K; ^5 s1 h" {6 P
! w+ K8 x/ u& q& N7 ?2 ^/ e$ d
如果团队有人举了2根或1根手指,ScrumMaster需要请他/她讲述自己的顾虑,困难在哪里。如果团队认可他/她提出的困难会影响Sprint目标的达成,则应该调整Sprint目标。
1 U" {) c4 f6 ]/ y
Sprint计划结束的时候,不仅团队承诺了Sprint目标,而且SprintBacklog也得到了团队的承诺。团队可以将SprintBacklog的用户故事和拆分的任务卡放到任务板上,作为Sprint第一天启动的站会输入。 9 k7 J9 m Y* b1 C1 Q/ O
: [+ C/ c- M! O; ~/ H# o; J1 ] |