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 | 标签为 , , , , | 留下评论

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”.


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

And some other webpages, sites to browse further.

发表在 未分类 | 留下评论










发表在 未分类 | 留下评论


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








发表在 未分类 | 2条评论

“是什么赶走了高潜质人才” —— 哈佛商业评论7月刊


作者是琼 " 马丁(Jean Martin)康拉德 " 施密特(Conrad Schmidt),他们开展了一项有关领导力发展的研究,发现,企业高潜质人才在内部变动工作后,近40%都不成功。从这些调查中,作者发现了一个普遍的事实:大多数管理团队在努力培养下一代领导人时,都犯有严重错误。

  • 错误1:认为高潜质人才高度敬业:20%的员工“高度不敬业”,从2007年上半年的8%增加到了2009年的这一比例。
  • 错误2:把当前高绩效等同于日后潜质:70%的高绩效者缺乏在未来岗位上去的成功所需的关键素质。新星人才应该具备的素质包括,(1)能力,即拥有智力、技术和情感技能;(2)敬业度,员工自身感到的对企业及其使命的关联度和投入度;(3)志向,指员工的认可、晋升和未来回报的愿望,以及员工自己的期望与企业对其期望的契合。
  • 错误3:将管理新星人才的责任下放:往往会出现这样的情况,人才选拔只看眼前的业绩;业务部门对人才提出的要求比较窄,而且更多注重当前所需技能,而不是着眼于未来,因此人才获得的发展机会比较少。另外一线经理还可能“囤积”人才,把人才搜罗到自己手下,并严加保护,不肯在公司范围内分享。
  • 错误4:过多地呵护新星人才:只有在真实的压力环境下,领导者才能真正成长起来。
  • 错误5:指望明星员工与企业“共度时艰”:最基本的一点是“员工所得应该与贡献大小相一致”。如果你搞平均主义,就等于没有尽力去支持和留住那些对你最重要的人。
  • 错误6:没有把明星员工与企业战略联系起来:事实上,我们的研究表明,高潜质人才对管理者及企业战略能力的信任度,乃是支持他们敬业度的最有利的因素之一。



  1. 明确检验备选人才在三方面的素质:能力、敬业度、志向。
  2. 在选拔培养对象时,更多地强调未来所需的能力(由企业增长计划来决定),而不是根据一些当前的业绩表现。
  3. 将高潜质员工视为企业增长的稀缺性资产,并从企业层面管理他们的数量和质量。
  4. 忘记老一套的职能或业务部门轮岗做法,把年轻领导安排到高强度的岗位上,并为他们制定明确的挑战性发展目标。
  5. 找出企业内部风险最大、最具挑战性的岗位,把新星人才直接安排到这些岗位上。
  6. 制定个人发展计划,把个人目标与企业的增长计划,而不是一般能力模型联系起来。
  7. 每年对优秀人才做出评估,看他们在能力、敬业度和志向方面有所进步。
  8. 给予明星员工显著的差异化薪酬和认可。
  9. 培训项目经理与高潜质员工之间定期进行开诚布公的交流,以了解明星员工的成长情况和满意度水平。
  10. 不是向成长中的新星人才泛泛地传达公司的战略,而是提供个性化的战略信息,强调他们的个人发展如何与公司的增长计划保持一致。






发表在 活到老学到老 | 留下评论




接着是今天去蹭CSDN的TUP活动,经过一条马路时看到地上的斑马线,如今办证的兄弟实在是牛叉,这地方都利用起来的,而且还很显眼,估计学过色彩。TUP是Technology、User Experience、Product的首字母缩写,嘉宾是来自人人网、新浪围脖的高手,他们分享的都是网站架构、搜索、内存啥的,不太听得懂。。。




发表在 未分类 | 留下评论










  • 免费洗衣(每日限额140元,含15%服务费金额,可以累积)
  • 免费享用房内迷你吧软饮(每日可享用6听软饮料:可乐、雪碧、果汁、苏打水。不可累积)
  • 免本市通话费(声讯台除外)


发表在 未分类 | 2条评论