Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

In coaching several agile teams and sifting through long lists of metrics, I've observed a core set of metrics that can help distinguish successful teams from teams headed for schedule slips:

Juggle

Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time.

Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions.

Plan leak

This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning.

Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work).

In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates.

Execution leak

Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less).

Jelly

This shows how much unplanned work was added during the iteration.

In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints.

What do you think? Have you used these metrics? What metrics do you use to help spot trouble?

I like the Juggle metric. I think agile works best with teams who know how to work together. When people are on many projects, there is not really a team, just a collection of people called a team. This is a big clue that you are not going to be getting the advantages of agile.

The other three metrics are all about planning. The biggest thing that brought me to agile is the realization that most of the planning on my projects was of little value. In American business, you have to give the rest of the company useful estimates, expected dates, resources required...But it doesn't have anything to do with productivity or ROI; it is just something you have to do to survive. I don't see the ability of team leaders to generate planning metrics as an indicator of success or failure.

In Kanban and many Scrum implementations, you don't even estimate task hours. The best metrics come from measuring stuff produced (stories completed) per unit time. If stuff is not produced quickly, that is an indicator of high risk. In agile you get regular deliveries that can be measured, so you get early indicators.

One of the huge advantages of agile is that people shuffle around to help each other get the most important work done. The term "agile" means doing stuff that has to be done, but is not in the plan. If your metric measures the difference between the plan and what gets done, you are punishing agile behavior and rewarding good old top down, waterfall organization.

Posted: Feb 26, 2012 11:57 PM

PM Hut

These apply to projects across the board, not just to Agile projects. In fact, the word agile can be removed from the article and it'll still make sense!