关于Burn down Chart

[熊 俊]

Hi all

有个问题，如果SCRUM团队在一个迭代中发现burndown chart下降的比较快，生产率比预定的要高，这个时候PO会从任务图板上把下个迭代中的一些任务提前到这个迭代来完成。

那么，这些被提前的任务该放在Unplanning Item中呢，还是放在正常的的任务列表中呢？此外，这些被提前的任务的加入，是否要改变burndown chart？我的意思是说，这些被提前的任务也有它们自己所包含的Story Point，这些任务加入到现在的迭代中时，是否要让剩余未完成的Story Point增加呢？还是保持原有的预定的生产率不变？

[Xu Yi]

2009/11/18 熊 俊 ans...@gmail.com

       那么，这些被提前的任务该放在Unplanning Item中呢，还是放在正常的的任务列表中呢？

 

这两种选择对你来说有哪些区别或者有什么影响？

 

此外，这些被提前的任务的加入，是否要改变burndown chart？

 

如果不改变burndown chart，你准备怎么处理这些被提前的任务？如果改变burndown chart，你又会如何处理呢？

 

我的意思是说，这些被提前的任务也有它们自己所包含的Story Point，这些任务加入到现在的迭代中时，是否要让剩余未完成的Story Point增加呢？

 

有什么区别？有哪些方面的区别？

 

增加和不增加有哪些影响，都是哪些方面的影响？

 

还是保持原有的预定的生产率不变？

“生产率”在你们的环境中的意思是？你们会怎么使用这个数据，为什么是否增加任务和保持“原有的预订的”生产率有关系？

--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -

[Wavel]

如果估计新加的task能在sprint结束前完成，为什么不能加进来呢？这样team在sprint中earned story point也多了。
我没太看明白你说的新加的任务怎么只加到剩余未完成的story point, 如果新加task的话，sprint story point也会变
阿。

可以和scrum team讨论一下，看看大家的建议，毕竟scrum强调team management。经常出现这种情况的话说明team
velocity提高了，可以在planning meeting的时候考虑多加一些user story。

另，你说的生产率是什么东西啊？

[熊 俊]

感谢各位的参与，其实我的疑惑来自于对下面几张图的不理解：

[Xu Yi]

2009/11/20 熊 俊 <ans...@gmail.com>

********************************************************************************
我的疑问在于，未经Planning Meeting计划的Backlog，应该放在左侧，还是Unplanning Items中，

我自己认为：

放在左侧可以比较好的管理好进度状况，就是说可以有task的checked out和done的状态。
放在Unplanning Items中呢，就是没有办法这样做了因为这样所有的一切东西都只存在这么一个小小的区域中，但是可以看到有多少个Unplanning Items，放到左侧就看不到了。

（或许可以把这些未经计划的Backlog放在左侧，然后Unplanning Items中也留一个记号？你们是怎么处理这样的情况的？）

********************************************************************************

如果你一定要使用这种taskboard方式，我会选择在两个地方都留下标记。在upplanned item里放一个index card，记录item的名称就可以了；在左侧not checked out放上item名称以及具体的tasks。一个用来管理进度，一个用来提醒大家（主要是PO？）有些item是临时添加的，破坏了“NO Change”的原则。

 

task board是一种information radiator，它的作用在于展现sprint的真实信息，所以，只要信息是真实的，怎么爽就怎么放吧。

 

********************************************************************************

另一个疑惑是硝烟中的这段话，可是这里举的例子是原定的5个backlog有3个顺利完成，其他2个没有完成的情况。

可是，如果有一些新增的Unplanning Items的话，那么到底要不要增加实际velocity呢？还是纯粹使用原来的原始估算上？
因为这次会有Unplanning Items，下次也有可能有，要完全杜绝应该不太可能，因为我们做的就是面向终端市场的产品，变化很快。
如果Unplanning Items不计入velocity的话，团队的投入程度就会降低，好像也没有什么不妥，就是表示团队的投入程度不能太高了，因为可能出现不在计划中的任务。
以后Planning Meeting的时候就按照比较低的投入程度计算就好了。


不知道，我的理解有没有问题，你们有遇到类似的问题么？怎么处理？

********************************************************************************

 

velocity是用来干什么的呢？想清楚这个问题才能理清思路。

 

敏捷宣言里有一条原则是讲simplicity的，放到product backlog的管理来说，怎么样够simple呢？是不是里面的item只有两个状态是最简单的，DONE和not started？那么计算剩余多少工作，是否只有两个计算状态是最简单的，DONE了就全部计入velocity，没有DONE就是0？

 

为什么要严格计算velocity？随便google一下都能找到很多信息，就不多说了。我个人的解读简单粗暴点，就是自己的事自己搞定（或者今日事今日毕），不留给他人擦屁股，自己也不给别人擦屁股。那么最好的方式就是，按照DoD，DONE就是DONE，不DONE就是不DONE，不要耍嘴皮子。

 

不太理解你说的“团队的投入程度”是什么意思。我的理解的话，团队干了多少活就是干了多少活，计较velocity上的计算，不过是在耍嘴皮子而已，把没有DONE的东西说成DONE，那么你下次不是还得花额外的时间去解决剩下的东西，那么下一次的velocity不就少了？而且还不排除某些情况下就把这些剩下的脏活累活扔给别人去擦屁股了。那还不如没有DONE就是没有DONE，velocity也不计算这个item，反正等到下次做完的时候story point自然会计算进去，有什么损失吗？不就是拿到story point晚了点呗，别那么心急嘛。

 

按较低的投入程度计算，我觉得就是在预留buffer，你觉得呢？

[Anson]

 我说的投入程度是指：

我是说这些被做完了的Unplanning是否要计算到团队的实际生产率中，一边在下次的planning meeting中能够体现出来？

--~--~---------~--~----~------------~-------~--~----~
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
-~----------~----~----~----~------~----~------~--~---

[Anson]

此外，还有一个问题就是，这些Unplanning Items的Story Point是否要计算？还是由团队一起来进行估算？在Unplanning Item被提出的时候，还是在每日立会上比较适合呢。

在 2009-11-20，下午1:00， Xu Yi 写道：

[Xu Yi]

 

 

2009/11/20 Anson <ans...@gmail.com>

 

 我说的投入程度是指：

 

 

我是说这些被做完了的Unplanning是否要计算到团队的实际生产率中，一边在下次的planning meeting中能够体现出来？

 

在另一个帖子里面，和其他几个朋友一道，我已经表达了我对类似“投入程度”之类用法的态度。

 

对你所引用的这张图片，我只有一个看法，对我来说，velocity意味着类似于story point这样的相对大小值（衡量“size”），而不是hour（man-day应该也是类似的，但我不知道你具体的用法）这样子衡量“duration”的时间单位。

 

此外，还有一个问题就是，这些Unplanning Items的Story Point是否要计算？还是由团队一起来进行估算？在Unplanning Item被提出的时候，还是在每日立会上比较适合呢。 

 

某个sprint的velocity = sprint结束时，符合DONE标准item的story point值的和。 非常简单的算术。

 

另外一点，看到这里我很迷糊，请问你的“story point”究竟是什么意思，有没有具体的实例可以参考一下？

 

以及unplanned item究竟是哪些东西，如果是来自于product backlog中的item被提前放入当前sprint，那么基本上（或者通常。。）应该都是已经有估计好的story point值存在（在backlog grooming session里），套用前面的公式，就可以计算velocity。如果是指突如其来的客户缺陷报告，那么需要用其他方式来处理，此处不铺开谈。

 

daily scrum对我来说，只有一个意义“交流status”，大致也就那么3~4个问题，我不会在这里讨论这些unplanned item。对于sprint content的更改，首先，我认为是不应该发生或者应该极少发生的特例；其次，如果有更改，必须是和PO在一起商讨，因为如果在sprint planning上，团队按照自己的capacity去commit所要完成的item（或者叫feature）的话，那么任何的unplanned item都意味着有其他的item将被放弃或者无法完成，这样的情况都必须和PO沟通，确认PO认同这样的变动。在我看来如果不是这样的方式处理的话，要么团队在commitment上面撒谎了，要么就是PO工作没做好该承担的责任没有承担。

[lotin]

能完成的话，应该要加入新的任务。不过开发团队要确认是否能够完成。我们团队在实践初期也常发生提前完成的情况，但是后续发现其实是团队成员没有严格按照验收标准完成，所以还是质量第一.

2009/11/20 Xu Yi <kave...@gmail.com>