Quote Ron Jeffries on Velocity

In previous post “Velocity is Story Points per Sprint?”I mentioned that velocity could be the accumulated story count / accumulated sprint, and I saw it from Ron’s reply in one scrumdevelopment group discussion.

Unfortunately I didn’t save that post, and I couldn’t search and find it now, however I found a discussion from last year in the group, I quoted some of Ron’s comments here, it reflects the same idea.

Charles Bradley posted a question in the group, “Should I assign Story Points to bugs?” and triggered the discussion. I thought following replies from Ron are worth reading:

And some brief quotes below:

    Velocity is stories done per unit time. And that’s all there is.

  • The primary value of velocity is to know [roughly] when we will get somewhere. Using past velocity to estimate how much work to take on next week is OK, but it isn’t the point. The point is to use progress to date to predict future progress.
  • I don’t recommend velocity.
  • Just count what’s done. Time spent fixing bugs is waste, and it will be shown by the amount of work done being reduced.
  • Velocity is /defined/ as the number of stories the team completes per unit time. The notion is specifically designed not to be “the amount of work” the team completes, because the focus should be on what the customer (product owner) wants.

So, actually count velocity as number of stories the team finished per unit time is not an alternative, it’s actually how it is used in the beginning when XP guys invented it. Does it surprise you?

发表在 Agile&Scrum&Testing&TA | 发表评论

Velocity is Story Points per Sprint?

One colleague was complaining about the Velocity practice, one part is the definition of Velocity, he says:

  • In Scrum, we define velocity as the average of the story points finished by the team in the last “x” sprints.

Well, I have different opinions. When I first check their discussion, I want to jump out and say “you’re wrong on velocity!”, and I tend to refer to Mike Cohn’s definition to it. Well, after read the “User Story Applied” (2004) carefully, I found I would not prefer the way how Mike explains velocity:

  • Page 15 “Velocity is the amount of work the developers can complete in an iteration.”
  • Page 91, “We use the term velocity to refer to the number of story points a team completes (or expects to complete) in an iteration.”
  • Page 103, “As we learned in Chapter 8, “Estimating User Stories,” velocity represents the amount of work that gets done in an iteration.”

To me there is a sequence:

  1. first you choose a measure for your requirements (remember it doesn’t have to be user story), e.g. story points or ideal days
  2. compute the velocity based the measure you choosed
    • if you choose story points, velocity = accumulated story points / accumulated sprint count
    • if you choose ideal days, velocity = accumulated ideal days / accumulated sprint count

And I’d only use velocity to represent what happened, not “can”. Which means only compute it for pasted sprints, e.g. after a sprint review. And basically I don’t recommended using the term “velocity” while estimating how many things could be done, in the sprint planning, I would just call it “estimates”. To avoid confusion.

In my opinion, story points and velocity benefit the product owner the most, instead of the team. Coz the team could mainly rely on e.g. hours to plan and track progresses of their sprint. And it’s very easy for the team to keep a constant measure relation along the time. While for the product owner, in charge of several teams’ work, it’s very hard to keep a constant measure relation in the backlog, and story point or ideal days could help. Therefore I would make an explicit distinction that PO relies on relative size, team relies on definite estimates.

We must remember there are also teams who don’t estimate for user stories at all. As Ron Jeffries mentioned in scrumdevelopment yahoo group, they just split requirements into the same sized small user stories, and don’t estimate at all. So managing sprint is the easiest by just counting the number of stories, the velocity of their teams would be really easy too:

  • velocity = accumulated story count / accumulated sprint count

Who says velocity has to be with story points?

Some other links you might want to check out:

发表在 Agile&Scrum&Testing&TA | 发表评论

Scrum/Agile Starter Kit

If you’re new to Scrum, and wants to know how you can start, this is the post for you.

Please kindly comment on this post to provide your thoughts and your recommendations on whatever resources helped you on your journey to Scrum/Agile.

Part I: You could browse my blog on my experience on Scrum and Agile, or browse the site www.kaverjody.com. If you couldn’t access it, please try the Sina Blog, it contains all my old blog posts too. Posts including:

Part II: And you could first read free resources from the internet:

Part III: Blogs of Scrum or Agile gurus:

Part IV: Recommendations from other places:

发表在 Agile&Scrum&Testing&TA | Tagged , , , , | 发表评论

Move to kaverjody.com

From now on, I’ll no longer update this blog site, and move my focus to the personal domain at http://kaverjody.com. My current blog entries on this site will be imported to the new site, and I’ll keep updating my contents there. If you have any questions or issues, please contact me via kaverjody AT gmail.com.

发表在 未分类 | 发表评论

Tribal Leadership

Required by Maarit Laanti to watch the video of Dave Logan on Tribal Leadership at TEDxUSC, which turns out to be a good read. He wrote a book named “Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization”.

http://upload.wikimedia.org/wikipedia/en/6/64/Tribal_leadership2.jpg

There’re some more resources you might want to dig out:

And some other webpages, sites to browse further.

发表在 未分类 | 发表评论

又一本无趣的书《30年后,你拿什么养活自己》

上周在公司的员工俱乐部借了本书《30年后,你拿什么养活自己》看,被它的表面所欺骗,以为是刘彦斌的书,结果后来才发现是他对剑而已。不过从我读完的感受来看,哎,也一样是被骗,口水书而已,讲的东西大同小异。

书中的内容其实和多数的理财类书籍都差不多,也就讲那么一些东西,从这个角度没什么好评价的。虚构出一个主人公和围绕着他发生的故事,从而讲解进行理财的必要和方法。它所讲到的社会现象也都是事实,比如说中年危机,期待着早日退休享受生活,对于社会保险制度的不信任,等等。

不过我始终觉得这类书籍最根本的一个问题在于,通常他们都会将理财的希望放在投资回报率上,通过持续投资累计资本,以及坚持长期投资以利用复利来快速增加资本金。当然不同的投资渠道也有不同的投资回报率,当然要加快财富积累的速度自然要提高投资回报率。但问题在于,投资回报率何来?

非常简单地来看,作为一个人来说,既是生产者也是消费者,还是投资者。那么这个生产者利用生产资料生产出商品,获得劳动报酬;投资者利用生产者的产物出售牟利,支付劳动报酬,获得经营利润;消费者支付费用获得商品。用数字做个简单的运算吧,生产者利用价值20元的资源生产出产品,投资者以100元出售此商品,支付给生产者60元的劳动报酬后获取20元的利润。也即我们可以看到,劳动者/消费者的收益为-40元,投资者收益为40元,(包括自然界的应获收益20元,假设其所有人为投资者,例如其受控的政权)。由于所有与人相关的支出、收入都在人间界的循环中被抵消,剩余的唯一变化也即是自然资源从自然界转移至人间界过程中创造出的价值(以人间界的财富标准衡量)。

在这样的情况下,任何的扩大投资回报率的行为最终都会体现在,对另一方的剥削,或者是对自然资源的进一步压榨。假设投资者希望提高10%的投资回报率,所以其将商品售价提高为110元,那么其得到50元利润。劳动者/消费者的收益为-50。也即劳动者/消费者的投资回报率下降,于是其追逐更高收入,提出将其劳动回报提高至70元,以抵消物价上涨的影响,由此双方收益比回到40元和-40元,依然是平衡的。但各自的投资回报率均有下降,因为基数变大了。将此循环继续下去的话,就会变成资本泡沫,也即数字的不断增大,而双方受益依然保持某种程度的平衡。回过头来看收益回报中的人间界、自然界对比,可以看到20/20、30/20、200/20、xxx/20等,也即是在总量不变的自然资源上通过抬高价格来构造虚假繁荣。

另一种方法则是增加对自然界的剥削,利用更低廉的成本获得更多的自然资源,增加自身的利润。由于自然界在人类利益链条中的缺席,其只能承受被不断剥削的命运,当然最后其收回其应得回报的方式既是极端的自然灾害。但在其成本短期不可见的情况下,我们可以看到投资者收益变作50元(20/30),由于售价保持不变,劳动者/消费者收益为-40元,投资者提高了自己的投资回报率,倒霉的是自然界。

片面地追求提高自身投资回报率的行为只会导致更严重的资产泡沫和自然界报复,一个和谐发展的人间界应该是和自然界融合的。类似于阿凡达的世界,人类、自然融合一体,共同进步,而后更大范围,则是与宇宙的共同进步。提高自然资源在人间界、自然界的运转效率和运转效果以提高生活水准(而非是财富水平),财富水平从人间界单方面出发去判断,没有估计自然界的损失,而生活水平的说法则适用于人间界以及自然界的生物(也包括非生物?)。

而我反感此类书的原因也在如此,它让整个人间界向着不和谐的方向前进,此类书的影响力越大,其前进的速度越快,自然界受损或泡沫增长的速度也越快。管理学界、政治界以及其他很多组织都在宣扬可持续发展,可我们更应该宣扬的是否应该是人类与自然的协同发展,可持续的发展和进步?

发表在 未分类 | 发表评论

烤鱼@江边城外+酒店细节

晚上和WCB同学约好吃饭,大家离得蛮近的,打个车也就13块的距离,他选择了“江边城外 巫山烤鱼 霄云路旗舰店”,网上搜索准备给这个店加个链接,结果发现它不像往常一样在大众点评网上有介绍(更奇怪的是,我记得除了大众点评,以前还有另一个很有名的相似网站,可我突然一下怎么都想不起、也找不出这个网站叫什么。。。)。

它家的烤鱼的确不错,应该也不是很贵,照片上这个烤鱼好像是3斤多,同学付的钱,这顿饭大概120元吧,烤鱼确实蛮好吃,挺入味的。至于WCB同学,厉害啊,做信托的,问他收入多少,说了个不低的数字,人家微微笑,“要多一点”。老同学见面,这家伙却没咋个变,就是人看起来更精干,而且可都是和什么绿城、宋卫平这些人打交道,按他自己的说法是变得很爱玩,不只是旅游,以前还喜欢泡吧啥的,一直在踢球,还有打羽毛球,K歌之类的,可谓爱好广泛。

DSCN0066DSCN0064[4]

丽都比较历史悠久,房间、地毯都挺旧,但这里的工作人员却让人觉得很舒服,个人感觉很有服务意识。讲几个今天回来的小细节和一些和以往住店不同的地方吧。

第一是以往都不会去消费迷你吧里的商品,这次行政楼层里可以每天免费享用6听软饮,所以一直还都有在消费。。。从前天起,他们都会在桌上放一个单子,是我前一天所消耗的迷你吧商品。另一点不一样的是水果,以前在成都的国际假日,酒店每一周给我送一份水果,这里,大概是因为楼层的缘故,每天都有新鲜的水果(梨、苹果、香蕉),大家可以看到我前几天还没吃的苹果+梨,以及另一张照片里今天新摆放的水果。

DSCN0069DSCN0070DSCN0071

洗衣后送回房间的服务稍有不同,以往都是,衬衣、T恤的都直接挂到衣柜,其他的放在篮子里,此处则是包得恭恭敬敬的放在桌上。另外,以前我也喜欢把要换洗的脏衣服用洗衣袋放着,稍微积几件再送洗(只是懒得写那么多洗衣单),他们似乎看见我有在洗衣袋里放衣物却没有填单子的话就会留下一张通知,告诉我说很抱歉没有收洗我的衣物。另一点是房间里的矿泉水,早上出门前我打开一瓶矿泉水喝过一点,而后就随手放在办公桌上,晚上回来,发现这半瓶水和新的两瓶水都放在床头柜上,也就是一贯放矿泉水的地方。

DSCN0068DSCN0072DSCN0073

发表在 未分类 | 2条评论