某项目组第一次采用敏捷方法进行开发，确定了迭代周期为三周。该项目组投入的资源如下：
前端开发工程师一名；
后端开发工程师一名；
测试工程师一名；
PO一名；
SM一名；
前后端开发采用不同的技术，熟悉前端开发的工程师不熟悉后端的技术，后端开发的工程师也不熟悉前端使用的技术。
当第1周结束后，由于前端开发人员使用的是新技术，需要熟悉新技术，而后端工程师与测试工程师的投入都不到位，因此估算工作量与实际工作量差别比较大。咨询顾问介入了解情况后，指出了本项目组在迭代策划时的错误，并指导项目组对后续开发活动进行了如下调整：
1.将三周的开发周期调整为一周一个迭代的开发周期。在不熟悉敏捷开发方法时，迭代周期要短，要及时总结经验教训，进行自我学习。
2.鉴于前期的迭代策划做得不好，需要重新进行迭代策划。
3.鉴于团队的成员不是全栈工程师，因此将按角色分别估计工作量。
4.测试人员需要尽早参与开发，而不是到第3次迭代才进行功能测试。
重新进行的迭代策划过程如下：
1.项目组全员参与了迭代策划会议。另外包括：
项目组外部的测试工程师两名；
外部咨询顾问作为主持人；
QA人员负责实时在电脑上按照更新后的模板记录估算结果，并投影出来；
其他多名观摩学习人员。
2.首先请PO讲解了每个用户故事，然后依次让前端开发工程师、后端开发工程师讲解开发要点，包括设计思路、需要处理的需求要点、是否有历史的复用功能、前后台的接口等；接着让测试工程师讲解测试要点、澄清需要测试的需求细节。
在此讨论中：
PO调低了某些用户故事的优先级；
PO删除了一个用户故事；
PO澄清了某些模糊的用户故事；
前后台的工程师指出了可以复用的功能；
前后台的工程师对某些需求的实现方式做了沟通；
测试人员贡献了很多澄清需求的想法。迭代策划会议的一个重要工作就是做需求的沟通，要求项目组的所有成员要对需求达成一致的理解。通过填写开发要点、测试要点、促使项目组成员对需求的理解进行沟通、讨论、确认。
3.前端开发工程师、后端开发工程师、测试工程师分别选择了一个故事作为基准故事，设置故事点为1，然后估算剩余用户故事的点数，从斐波那契数列中选择一个最接近的点数，犹豫不定时，选择偏大的点数。在做此估算时，前端、后端开发工程师、测试工程师都是背对背地、独立地进行估算。因为每个角色只有一个人，所以没有采用策划扑克的方法，并且充分信任每个工程师的估算结果。如果估算的结果不准确，则在第1个迭代结束后，再调整估算结果。
4.三个角色对于选中的基准故事，分别估计了自己的工作量，然后推算出其他故事的工作量，合计得到每个故事的总工作量以及每个角色的总工作量。
用户故事 |
优先级 |
前端实现要点 |
前端实现的相对规模 |
前端工作量
|
后端实现要点
|
后端实现的相对规模 |
后端工作量 |
测试要点 |
测试的相对规模 |
测试工作量 |
工作量小计 |
故事1 |
1 |
…….. |
34 |
34 |
…….. |
21 |
21 |
…….. |
21 |
10.5 |
65.5 |
故事2 |
2 |
|
|
0 |
|
|
0 |
|
8 |
4 |
4 |
故事3 |
3 |
|
13 |
13 |
|
13 |
13 |
|
13 |
6.5 |
32.5 |
故事4 |
4 |
|
13 |
13 |
|
13 |
13 |
|
5 |
2.5 |
28.5 |
故事5 |
4 |
|
1 |
1 |
|
|
0 |
|
2 |
1 |
2 |
故事6 |
4 |
|
8 |
8 |
|
|
0 |
|
2 |
1 |
9 |
故事7 |
5 |
|
|
0 |
|
|
0 |
|
5 |
2.5 |
2.5 |
故事8 |
6 |
|
8 |
8 |
|
5 |
5 |
|
5 |
2.5 |
15.5 |
故事9 |
6 |
|
|
0 |
|
1 |
1 |
|
2 |
1 |
2 |
故事10 |
6 |
|
3 |
3 |
|
3 |
3 |
|
3 |
1.5 |
7.5 |
故事11 |
7 |
|
1 |
1 |
|
3 |
3 |
|
1 |
0.5 |
4.5 |
合计 |
|
|
|
94 |
|
|
59 |
|
|
33.5 |
186.5 |
有些用户故事可能没有前端或后端开发的工作量，则以0表示。
5.让PO对所有的用户故事划分优先级。首先请PO挑出最重要的一个需求，然后再挑选剩余故事中最重要的一个需求，如果不好区分优先级，就定义两个需求的优先级同等重要。此时，其他团队成员可以提出自己的意见，直至大家对优先级划分的结果达成一致。在划分优先级过程中：
PO主动删除了一个可做可不做的用户故事；
当对所有的故事划分完优先级、并重新按优先级顺序排列后，PO又再次做了权衡，微调了优先级；
对于成员质疑的优先级划分，PO给出了解释。
6.每次迭代周期设定为一周。列出每个工程师在未来两周中每周可以投入到本项目的工作量（小时），表示开发能力。
|
第1周 |
第2周 |
合计 |
前端开发工程师 |
24 |
24 |
48 |
后端开发工程师 |
22 |
22 |
44 |
测试工程师 |
6 |
24 |
30 |
|
52 |
70 |
122 |
7.根据每周可以提供的开发能力，平衡需要的总工作量与开发能力，如果不能满足需求的总工作量，则裁剪优先级最低的需求，否则就需要提升开发能力、增加人员。由于估算的总体故事的工作量为186.5人时，超出了实际的开发能力122个工时，因此SM和领导协商增加了一个迭代，并且由于前端开发的工作量估计与实际能力差别比较大，确定再增加一个前端开发工程师。
8.根据用户故事的优先级，挑选了第1周完成第1个故事。第1个故事比较大，但是无法再进行细拆分为更小的故事，并且已确定再增加一个前端开发工程师，以确保第1个故事能够在1次迭代内完成，并将第1次迭代的周期确定为6天而不是5天。
9.在上次策划会议中已经将用户故事拆分为任务，因此本次估算没有再进行任务的拆分。留待责任人自己进行细拆分。
本次迭代策划会议共耗时1.5小时。第一次迭代策划会议估算了12个用户故事，合计估算为186.5工时；本次迭代策划会议估算了11个用户故事，总估算工时也是186.5个工时，但是删除了一个估算为17个工时的故事。虽然结果差别不是很大，但是估算的过程是不同的，上次估算并没有进行认真的需求沟通，而本次根据不同的角色分别对需求进行了充分地阐述，同时这是在能力平衡的基础上做出的迭代计划，项目组成员更有信心可以按照计划实施！
本项目针对迭代策划会议的敏捷实践，打破了常规的方法，变通执行，反而带来了更好地效果。这也意味着敏捷软件开发是经验型过程控制，只要符合敏捷的原则，可以根据项目组的实际情况进行变通。