Sunday, June 28, 2009

Velocity: Why don't people know how much Scrum teams can get done?

The velocity of the Scrum team is the number of story points they can turn into working code at the end of a sprint. This is used by the Product Owner to create a release plan with a realistic date. The investors at OpenView Venture Partners released that all the GANTT charts they were seeing at board meetings were wrong because the senior management did not know the velocity of their teams.

The image above shows a blue ball with a lower position than the red ball. However, the blue ball velocity is going up and the red ball is stable. Scott Young makes a profound argument that you would be a better person if  you based your life on a velocity based paradigm. See his comments on "Balancing Today and Tomorrow."

All great Scrum teams triple their velocity by removing impediments and the best teams do it in three sprints. If they continue to improve engineering practices they will stabilize at 5 times the velocity of a waterfall team. We see this consistently in case study after case study. And this is at less than 40 hours a week because if they work more they slow down.

So why are teams uncomfortable with velocity? Some teams have dysfunctional management that will use it against them. So root case analysis will reveal that management is destroying the Scrum. Go work for another company!

Some companies say they have stopped using the burndown chart because it depresses the developers as they fail all the time. Hire new developers!

50% of the companies who say they are doing Scrum can't get working software at the end of a Sprint so their velocity is zero. So that might be a reason for not calculating velocity.

Of the remaining 50%, over half of them can't pass the Nokia test so they would have very low velocity (if they knew it).

At OpenView Partners we invest in teams that  know their velocity and we look at a plan presented by management who doesn't know the velocity of the teams as complete fiction. Competent managers have plans supported by real velocity data.

Maybe there are other reasons people don't know their velocity?


Syed said...

I would say the reason most teams do not know their velocity is because they do not understand relative estimation. They see this as an extra step (and maybe question the worth the effort?) when they still have to do traditional estimation for sprints. At least that has been my experience in coaching teams.

Syed Rayhan

Tungano said...

Hi Jeff,

Argument/excuse I have heard is that velocity can only be expressed when resources are fixed (amount of people on team/project, same persons, same spans of time etc). Because of this they question the usefulness and whether or not the bookkeeping is worth their time.

I really like the 'yesterday's weather' concept though, perfect prediction is not possible anyhow. It think it's a useful planning utility.

David A Koontz said...

Are you confusing Velocity with Acceleration in this article? If velocity is increasing then acceleration is NOT zero, not steady velocity. Acceleration is very exciting but is not sustainable.

I find your generalization of 5 X Velocity of a waterfall team very interesting. Could you talk more about this remarkable stat, and the background.

As a CSP I would be hard pressed to claim any of the teams I've been a part of attaining 5X, but I've never done any study comparing waterfall team to scrum team. I do know which team I chose to work upon!

ereami said...

When management is unwilling to get the point about agile, velocity is worthless. When scope and release date is fixed, velocity is worthless. When it becomes a instrument of pressure and humiliation, velocity is worthless, and so on.

Most corporations would buy agile at first because they think projects will get fasters, yes, but that their precious fixed scope and time will be maintained. When things start to get to the wrong direction, they blame Scrum (or whatever), but they didn't manage to change their mindset.

Adapting a phrase by Ken Schwaber: "The hardest part wil take years, the rest will demand continuous effort for the rest of your life"

From Ford Co., "Culture eats strategy for breakfast every day".

Jeff Sutherland said...

When scope and release date are fixed, velocity is essential. Two recent projects come to mind, one in the U.S. (most important project in a 50B company) and Sweden (most important project in a smaller company). In the first case, projected date with waterfall plan was one year late. Actually delivery was on time. Second project projected delivery date was one year late. Incremental delivery with more than 80% of business value only two months late and customer happy.

In the first case, my Scrum consulting team guaranteed delivery earlier than plan but on time only if management removed impediments. The "Project Leader" team selected by the CEO was an executive VP and four VPs of business units. The executive VP said "No problem, Jeff. I used to work at Toyota!" At that moment I knew the project would be a success.

After three sprints we had velocity data that projected a delivery date almost six months late. The velocity of the teams would have to double to meet the date. We gave the executive VP a list of the 12 worst impediments in the company and told him to remove them. In four days, they were gone, showing that companies absolutely do not need to live for more than one week with impediments if they have someone from Toyota in a leadership position. They only keep their impediments because they want to hold onto them.

Doubling velocity is easy but only if you know what your velocity is and what impediments need to be removed. We delivered exactly on time and the effect on the company stock price made the ROI on this project many thousands of percent, so big it was incalculable.