关于Sprint中想到的数学游戏，仅仅记录了一个思维过程，不表示我认可或反对。

在一个Sprint中，计划的人天（MD）应该大抵和可使用的人天数据相当
而实际投入的MD也应该和计划可使用的人天数据相当

假设Team有五人，都没有假期，两个工作周是50人天
εEst.MD＝50
因为Sprint时间盒是固定的，因此有εEst.MD＝εAct.MD

而实际工作中，必然有很多计划外的工作事项，考虑到计划外的一定是实际发生的，为便于描述，我把这些计划外事项分两种：Act.Un1和Ac,tUn2。
其中，Un1指未被计划的和符合Sprint目标的工作，这些是在计划过程中被遗漏或无法估计的，比如在过程中发现要开发一个Testbad来帮助验证功能，或者为了一个bug调整逻辑
Un2指和实现Sprint目标无关的工作，比如被其他team或其他项目借调了一天。

把计划内实际发生的人天描述为Act.P

估算的任务时间为Est.TMD，实际任务时间为Act.TMD
理论上以下公式应该成立
Act.P＋Act.Un1＋Act.Un2＝εAct.MD＝εEst.MD

计划完成百分比：Px＝Act.P/εAct.MD*100%
Sprint内人员专注程度指标：Ax＝(Act.P＋Act.Un1)/εEst.MD

更复杂的计算方法是通过所有任务的评估和实际TMD的系列数据，制作正态分布图，利用两组数据的均值和标准差，获得估算偏差系数。

看起来很不错的想法，至少可以专注程度这个指标可以在反思或中帮助大家思考。

这是我的一个思考过，仅仅是思考，没有说要想做或者不想做。

-----------------------------------------------------------------

2010-12-20：我把这个放在agilechina@googlegroups.com中，希望能抛砖引玉。

-------------------------------------------------------------------

（王晓明）这是一个很有趣的统计方法。感谢泥泥的分享。我也分享一下我们团队已经应用和将要应用的一些衡量指标。

1. Velocity = Actual completed story points / Actual ManDays
可以讲这个数据在一个时间单元内进行图形化，从而分析trend

2. Velocity = Business value (revenue) of stories / Actual cost of xxx man days.
2.1. Velocity = Business value (profit) of stories / Actual cost of xxx man days.

这些是用来衡量你的business的effectiveness和profitability

3. Story life-cycle = Story estimates(story point) / story life (number of days from starting implement story to story going into production)
可以统计这个数据的平均，最大，最小和stdv，从而分析团队Effectiveness

4. 敏捷成熟度(www.aaladdin.com)
可以使用敏捷组织转型框架的评估指标进行评估。

Many thanks!

Best Regards
Xiaoming Wang

http://Aaladdin.com  -- Agile organization transition framework
http://blog.aaladdin.com  -- Professional project management
LinkedIn Profile: http://www.linkedin.com/in/wangxiaoming

备注

story life-cycle有广义和狭义的两种。广义的是指从story的诞生（story writing）到story进入生产环境被用户使用的时间长度。狭义的是从一个story被开发人员认领到进入生产环境被用户使用的时间长度。

这个标准是用来衡量一个团队是不是能尽快的将客户需求转化成客户可以用来实现商业价值的产品、工具。

这只是我个人的理解，希望大家分享各自的经验。