Recognize Project-Measurement Traps

Teams encounter several project-measurement traps, which you, as a leader, can help manage.

  • Managers look at the team measures instead of project status measures.

  • Managers try to compare teams using velocity or some other team-based measure.

  • Too few people review the cost-of-delay measures, especially when the team has WIP.

Those traps—the gamification of team measures—can create risks for your project. Here’s how to recognize and manage those traps.

Trap: Managers Review Team Measures Instead of Project Measures

Many teams use iterations and calculate their velocity as part of their measures. Velocity can help a team learn its capacity, as discussed in ​Velocity Is a Capacity Measurement​. However, just measuring velocity does not help anyone understand the team’s progress. Teams make progress when they complete features, as discussed in ​Show Feature Progress​.

Here’s the real problem: velocity is easy to measure. If teams have large features—really, feature sets—progress is much more difficult to see. However, managing velocity doesn’t help anyone understand the team’s progress.

If you can, avoid showing any manager a team’s velocity. If you must, explain the team’s capacity. Even better, ask the manager what information he or she wants. If the manager wants to know when to expect a particular feature, explain the roadmaps and the team’s cycle time. You might say something like this: “That feature isn’t on the roadmap for another three iterations. Once it gets closer, we can use cycle time—the average time it takes for us to release a feature—to tell you more about when in that iteration you might see it. And please check with the product owner to make sure the product owner knows how important this feature is for you.”

If you can, show the manager what’s working now, as the best measure of the team’s progress.

Trap: Compare Teams’ Velocity Instead of an Individual Team’s Progress

Sometimes managers don’t realize what velocity is. They only know it’s some sort of team measure. They want to compare one team’s velocity against another team’s.

The problem is that teams work in different domains, in different code bases, and with a different number of people. Velocity is unique and personal to a team.

Consider asking the manager what he or she wants to know. Does the manager want to see the feature throughput? If so, consider using the product backlog burnup chart or the feature chart from ​Show Feature Progress​. If the manager wants to see delays, consider showing the cycle time chart from ​Visualize Your Project’s Delays​. Maybe even measure the delays you see affecting the team.

Very few teams are comparable in an organization. Instead of comparison, ask the manager what she or he wants to know, and provide that.

Trap: WIP Is Everywhere

Teams have WIP for many reasons. One is when the team has partially completed feature sets, so those feature sets are not released. (See ​Show What’s Done but Not Yet Released​.)

Sometimes it’s reasonable for a team to produce a walking skeleton all over the product: a little in admin, a little in search, a little in billing. However, that approach has a cost in terms of WIP.

Sometimes the team has WIP in other ways. One team had a slow build system. Another team’s product owner had feature-itis (see ​Trap: The Product Owner Has Feature-itis​), and kept asking the team to produce features. The team never finished a feature set, not by design. The team didn’t finish a feature set because the managers and the product owner became impatient with the team’s progress.

Some other teams have the ​Trap: Experts Take Their Own Stories​, or ​Trap: Everyone Takes His or Her Own Story​

Here are some possibilities for your team:

As a leader, your role is to help the rest of the organization see the costs of continuing to work the same way.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset