Velocity: Some preliminaries

It is important to know the Velocity of the team.

What is velocity?

Each team has a DOD (definition of done).  The Team has small stories at the top of the product backlog.

When each small story, which has story points that estimate the relative effort, …when each story is “done-done” per the DOD, then the Team scores the 2SPs (as an example) toward their Velocity for that Sprint.  10 stories done-done at 2 SPs per story… that would be a Velocity of 20SP for that Sprint.

It is useful to think of Velocity normally as the average Velocity over the last 3 sprints.  That typically is what is sustainable into the future, and gives a more accurate picture that takes out the ups and downs of each sprint.

Is Velocity more important than Business Value?

Well, they are both important.  But Business Value (in the customer’s eyes) is more important than Velocity.

But assuming we can increase both Velocity and the BV of each story (of, let’s say, typically 2 or 3 SPs), then … let’s increase both.

Velocity has seevral advantages.  It is easier to measure.  It is more controllable by most of the Team.  We can measure Velocity for different Teams and different projects:  the value here is a measure that any Team or manager can use to help manage (in a agood way) the Team.  (Cross team comparisons are another story.)

Are there any assumptions?

In general the people in the innovation team (aka the Scrum Team) have often been badly treated.  Or lived under “less than ideal” circumstances.

So, we must change that reality to include the following.

Hours must be lower, not higher, as we increase our Velocity.  I’ll say a maximum of 40 total hours per week to get maximum velocity, business value and innovation.  (There is debate about whether 40 is too high or too low.  Clearly 60 is too high.)  And much of that 40 is toward “stuff outside the team” and other “lost time”.  Maybe 60% is useful toward our product (our Team).

Also, the Team must be having more fun, or greater happiness, as you prefer.  The Happiness Metric (see Jeff Sutherland’s blog) is a good way to measure.

It should go without saying that Velocity is never achieved by cheating…that is, by saying that something is done when it is not.  By not fixing all the bugs, or in some other way reducing the quality and pretending to be finished.  That should go without saying — but notice that I felt somehow I had to say it.

One Key Benefit

Velocity is a key measure to help the ScrumMaster see whether he/she is fixing the best impediments for the Team (or getting them fixed).

With Team and people and organizations, it is hard to see how to prioritize the impediments.  Velocity gives purpose to the SM’s life.  Helps the SM see.  Helps everyone see the value of an SM.  Helps everyone prioritze and get stuff done.   That is very useful.

***

More to come.

 

 

« « Why not? || Velocity: How is it useful? » »