讲师： Alan Atlas 目前是Scanbuy, Inc. 的技术总裁。从事专业技术超过30年。从布朗大学的心理学学士，到麻省大学电机工程学士，他随后加入了贝尔实验室作为一名硬件工程师，然后迅速去乔治亚理工学院并拿到了电机工程硕士学位。在贝尔实验室的那段时间，他接触了软件，并自学了C语言编程。进入软件开发领域以后，Alan花了一些时间在数据获取工作站的实时UNIX内核中开发内核功能。被升级为OS开发组经理后，Alan开始了25年的技术经理生涯。在这期间他荣升至高级副总裁级别，之后他自动降回开发部经理，因为那个职位好玩很多。那些年的主要事件包括OSF Motif 1.0的发布和AvidNews 1.0的发布。AvidNews 1.0是行业中获奖的广播新闻管理系统，由Avid技术支持。 在亚马逊担任网络服务部高级开发经理时，Alan发现了Scrum。他成为了认证ScrumMaster，并带领他的团队在使用Scrum一年之后，成功发布Amazon S3。这成为Codie奖获奖的网络服务，提供了无限网络连接存储。Amazon S3项目的成功，以及Alan对Scrum方法的热爱，使Scrum在亚马逊网广泛散布开来。Allan成为了认证Scrum培训师和亚马逊第一个全职敏捷培训师和教练。他的经验使他立志成为认证Scrum教练，然后转换职业为全职敏捷教练和培训师。Alan在2009年敏捷大会和慕尼黑Scrum聚会中做过演讲。 话题介绍： 多年来估算的技巧一直是Scrum里面困扰着大多数人的领域. 让我们大家一起在Alan大师的引导下来重新细细的审视这门技巧. 使之变得更简洁, 更加符合敏捷的理念. 为什么需要估算? 多久（重）估算一次? 我们可以不使用传统基于复杂度,时间,心力,以及怀疑的估算方法吗? 在本次的演讲当中, Alan大师将为听众比较不同的估算法, 包括了Wideband Delphi, Planning Poker, The Team Estimation Game, 以及The Backdoor 等方法之间的差异. 何时应该估算工作量和团队的能力? 为何我们应该同时考虑理想时数和故事点数? 它们之间又有何不同呢? 以上所有的疑问都将由Alan 大师以其十多年的敏捷以及Scrum的经验和独到的见解为您解答。

1. A Fresh Look at Estimation
敏捷估算的新视角
Alan Atlas

3. Alan Atlas CST, CSC
Agile Conference 2012

4. http://www.flickr.com/photos/teuobk/2104039823/

5. http://www.flickr.com/photos/elenchos-seattle/3839827249/

8. 8

10. “I think we will be
able to release this
feature five sprints
from now.”

11. “This feature will
cost two complete
sprints of our 5
person team.”

12. “I think we can
deliver this project
in 8 sprints.”
(Actually we think 6 but we’re padding
to be careful.)

13.  Estimation does not create value. (估算无法
产生价值)
 Estimation does not reduce work. (估算无法
减低工作量)
 Therefore, estimation is ‘waste’ in Lean
terms. (因此, 从精益的角度来看, 估算是一种’
浪费’)
 And…
 Estimates can be mistaken as commitments
(同时, 估算时常被误认为就是承诺)

16.  To form an opinion about; evaluate. (形成一
个意见; 评估)
 A tentative evaluation or rough calculation,
as of worth, quantity, or size. (一种暂时性的
评估或者大概的有关於价值, 数量, 或者大小的
计算)
 A judgment based on one‘s impressions; an
opinion. (根据一个人的印象所作的判断)
 Usually implies a subjective and somewhat
inexact judgment (通常隐含了一种主观且不
怎麽準确的判断)

17. An oxymoron is a phrase in which
contradictory terms appear side by side.
(Oxymoron 指的是在一句话当中出现两个观
念相衝突的字或词)

18. “I’m almost positive we are done.”
“It was a dark night and the moon
shone with silvery light”
Detailed Summary
American Culture
Military Intelligence
Adult Male

19. Accurate Estimate
(準确的估算)

21.  Here is a question I can answer:
 How much effort can your team apply to the
project during this sprint?
 Here is a question I cannot answer:
 How much complexity can your team complete
during this sprint?
 Hereis what I do when I can’t answer a
question:
 I make a guess!

24. 24

25. S L
1 2 3 5 8 13
1 2 3 5 8 13
1 2 3 5 8 13
1 2 5 8
2 5
2
25

26.  Wouldn’tit be nice if every story was the
same size?
 Every story is then a ‘1’, or else a ‘247’. It
doesn’t matter.
 We can do that by splitting stories until they
are all about the same size.
 This gets us all of the benefits of splitting at
the same time that it eliminates estimating.
 No need to estimate.
 This works exceptionally well in kanban.

28. Story Task Pts Ideal
Hours
Consolidated 13
Financial Report
Design Integration 2
Data Structure
Import from first 6
data source
… … … …

29.  Mike Cohn once said:
“If you are not comfortable with story
points, then just pretend one story point
equals one ideal day.”
 Mike Cohn forgot to say:
“Only do that until you figure out story
points because it is not really true. It is a
trick to help you get started.”

30.  Use ideal hours for tasks
 Tasks are small and so are hours.
 Ifyou estimate effort, then story points and
ideal hours are correlated
 More story points means more ideal hours
because both estimate effort
 Now, since you estimate stories and tasks
differently, the two estimates can be used as
a sanity check

31. Story Points Sum of Task
Ideal Hours
Display Time 2 4
Enter Time 5 9
Scale
Change Time 3 5
Display
Set Y Axis Scale 1 12
Change Y Axis 3 7
Scale
Add Graph Title 3 5

32.  Variable part timers (隨時在改變的臨時工人
員數)
 Specialists (專家)
 Learning curve (學習曲線)

33. Team Percent Project Days Total project
Member Allocated Hours per Available hours
day this sprint available
this sprint
Xianshen 100 6 10 60
Brenda 100 6 8 48
Li 50 3 10 30
Mei 100 6 5 30
Jiang 100 6 10 60
Daniel 100 6 10 60
Total 288
Minus 10%
Scrum
Overhead
260
33

34.  Always estimate  Estimate when
 Relative estimation necessary
using Planning Poker  Estimate by splitting
 Story Points and Ideal  Affinity estimation
Hours  No task estimation (or
 Capacity Planning no tasks!)
 Complexity, Effort,  Capacity planning
and Doubt when necessary
 1 Story Point = 1 Day
Old Days Nowadays