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


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

And some other webpages, sites to browse further.

发表在 未分类 | 发表评论










发表在 未分类 | 发表评论


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








发表在 未分类 | 2条评论