# Is Iteration Strength a valuable parameter for you?

We all know how to use Iteration Velocity parameter. However, there are situations during an iteration that one takes an unexpected day off, or there is a bank holiday, or there is another reason for one not to work.

In such situations, you can use Iteration Strength which is kind of a "normalised velocity" that takes into account actual man-days during iteration.

Do you use Iteration Strength in your projects? Is it valuable information for you?

The idea behind the question is that I've heard two opinions:

• "I don't care about the strength, it will all be visible in the velocity after a few iterations"
• "yes, it is the actual team performance"

and I wonder how you feel about it.

Velocity is based on guessed values, and a median over the last few sprints/iterations. Therefore, the value is not exact as such, but it is "exact enough" for looking into the future of the next few iterations.

If you have a team of 8 people working in two week iterations, you would accumulate 80 man-days of "working power". If you want to recalculate the velocity based on 2 or three missing people for a day, you vary the velocity in ranges of 2 to 4 percent, which is a kind of white noise deviation.

On the other hand, if the iteration timeframe crosses Christmas and New Year, and more then half of the team is gone, you might consider that your velocity will be halved.

But my experience is that in this case velocity will not be halved but close to zero, because key people are missing, and those who show up are thinking about other things. :)

Velocity is not some linear scaling factor and as such is not so good for standard calculus methods.

• I like your observation that velocity is not in linear dependency with number of people in a team, +1. Apr 2, 2012 at 13:46

I don't think that there is a difference between velocity and iteration strength. Both are for the teams so that they can make a more realistic commitment at the sprint planning. If you have less team members on board your velocity will decrease, if not then you found a bottleneck. If you are using velocity for release planning then it is a different story. In that case revise your plan with the latest velocity number, because that is the more realistic one.

If the team is interested in analyzing it's performance, then by all means do not stand in their way. If they are faithful to retrospect, they will decide if it is a valuable practice and will choose to amplify or dampen the practice.

If this metric is being asked of them, beware. This is a management anti-pattern I've observed on a number of occasions. It expects a level of precision out of the team's forecast that is tantalizing but rarely possible. At best, the guidance by such metric will be hit and miss.

In all things, the Development team should be taught and encouraged to self-organize. The most reliable method of learning in a complex environment is empiricism.

I don't put much stock in Sprint strength calculations. I find there is little R.O.I. on the time I and others have spend calculating it. It is far better to simply ask the team what work from the Product Backlog it expects it can get to "Done" in a particular Sprint given the circumstances particular to that Sprint.