We’d rather use it to understand the importance of not getting drawn into a kind of “quick fix” trap, for example.
Unfortunately in communicating that we are going to measure the velocity and failing in communicating the underline reason (justified by such “model”), is exactly the right way to fall into a quick fix trap, creating conflicts, backfiring all our good intention (and we know that the road to hell is paved with good intentions).

In that case, better not using any velocity metrics explicitly, and just coach the teams to write clean code.
Make sure doing relative estimates (if you do them, otherwise be sure the stories are small enough) and make sure that also the P.O. is able to prioritize the backlog items, by optimizing by “max value, min cost” (that means that the P.O. should have an idea of the business value of any backlog item).

In writing bad code we don’t learn anything, have stress, and the accidental complexity created will trashes any estimate slowing down everything.
In striving for writing clean code we can think better, learn better and hopefully have a basecode that will minimize the possibility of trashing the estimates (it doesn’t mean that we can formally prove it, or that there is a science behind that yet, but it doesn’t really matter. It’s craftsmanship).

Are you looking at how much of this slack time are you “actually” doing?

Sorry, I may make a lot of wrong assumptions for this example:

Two iteration ago you velocity was 42 and you had enough time for those “extra activities” that fit in you slack.
Last iteration a couple of stories bumped into issues and took longer, no time for “extra activities” but your velocity is still 42.
Team during the retrospective looks at its velocity and thinks that this has been another good iteration: 42 same as last time… and maybe also the PO looks at the velocity and thinks that everything is great…

You missed a chance to see at your lower velocity and start a conversation on what didn’t went well.

Slack is not “optional” and left for the end of the iteration.

Ilias

I agree that the real objectives are to deliver value, and to always improve. Other measures are just tools to help us reach that goal, and they may only be temporary tools that we throw away when they are no longer useful.

My point here is that when you have a team that is not yet to the point of reliably delivering value, it’s not a good idea to strive to deliver as many completed stories as possible. Maybe this is obvious to more experienced agilists, but it was not obvious to me :-)

It’s true that cleaning up the code and paying down technical debt are activities that *should* be done continuously. But it’s virtually guaranteed that a beginning team will *not* do this to the level that is actually required. It’s surprising how much cleanup the code *really* needs :-) So one way to make sure that the team takes the time to really clean up, is to make sure that they have spare time in their iteration. This at least is my current understanding.

I’m not sure what you mean when you say that adding slack may lead to hide problems; can you elaborate on that?

@Ilias and @roberto: I didn’t say that explicitly, but I completely agree that velocity is a measure that is not reported outside the team. This does not prevent pressure to deliver faster, though. Most teams deliver more slowly than is desired; I think we can all agree on this? It’s only natural that the developers themselves will try to do one more story, as long as they believe that the code is refactored enough. It’s easy for them to be wrong on this :-)

I don’t agree that maximising or stabilising velocity are an objective.
Velocity is only a value that we “read” to learn something about what we delivered.
Adding a variable/artificial slack to the iteration velocity can also hide other types of problems.

Deliver “value” and “maintaining quality” is the objective.
Aiming to a certain velocity number is always wrong.

When you mention “reducing technical debt, to clean the system, to improve the tests, to study, to perform technical improvements” …all of these activities should be done daily irrespective of the fact that in this iteration we have some slack left or not.

I’ve seen many times velocity used as a tool to keep high, low or steady the business pressure on the team but they are all misuses.
Velocity is only a tool to “learn” what we’ve done this iteration and what we can roughly expect the next one if the context remains the same.

Velocity is for capacity calibration, is not a productivity measure, is not a team pressure valve or gauge.

You may be interested in this:
http://jimhighsmith.com/2011/11/02/velocity-is-killing-agility/

Ilias