Truck Factor

Truck Factor (definition): “The number of people on your team who have to be hit with a truck before the project is in serious trouble”


Clearly “hit by a truck” is an extreme thought however you could easily substitute “take vacation at the same time” to get the same idea. If any part of your project has a truck factor of one then you are in a particularly fragile situation. If that one person leaves or is unable to work on the project, you will suffer the consequences.

Over time, anyone can be replaced. Truck factor is an indication of how expensive it will be to replace specific people.

In an ideal situation, everyone on the team will know all parts of the system so that the loss of any one person would have minimal impact. In reality, many projects rely on one or more “heroes” who are the only ones who understand certain critical parts of the system. When these heroes leave (and you should assume they will), you must be prepared to recover.

If you have a hero on your team, the best thing you can do is reassign that person to a different part of the system. This will allow the replacement to ramp up while the hero is still available for support. If you wait until the hero has left then the ramp-up will be significantly more expensive.

An added benefit to reassigning the hero is that this person will now have the opportunity to work on something different. Since the hero’s tend to be the most technically competent members of the team, this will usually mean that the new area will improve once the hero has worked on it for a while.

Truck factor is a quick metric that will highlight potential problems in your project. Having hero’s on your team can be very beneficial but only if you don’t become dependant on them. Truck factor is one metric that will highlight your dependencies.

Cross posted from Mike Bowler’s Weblog


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

3 thoughts on “Truck Factor”

  1. Truck factor is immensily important to keep track of for monolithic system architectures. I think reaching a factor of zero is possible if the codebase is small enough that it can fit into one person’s head easily.

    1. In his article “Communicating in software development” Heikki Hellgren addresses the problem of information exchange in the field of information technology. He identifies main obstacles in the way of establishing healthy relationships both among software developers and between software developers and their clients, namely ‘silent information’ – the bane of developer’s community, as well as the devastating effect of interruptions on person’s workflow. In addition, he provides an extensive list of solutions for the aforementioned issues. The structure of the article is cohesive and logical. However, backing for the main author’s thesis comes mostly from personal experience and common stereotypes which certainly doesn’t help credibility of his reasoning. In addition, some issues raised in the article are not properly discussed.

  2. It’s kind of an inverse measurement: A high truck factor means that a high number of people could be removed before you get into trouble. A truck factor of 100% would mean that the project has no dependency of any person.

Leave a Reply

Your email address will not be published. Required fields are marked *