This thread discusses the Content article: Agile Processes: Making Metrics Simple

We have struggled as an organization to have meaningful metrics for software development. There is no consistent direction "from above", and it isn't a priority for front-line managers. Developers record their time against tasks...but do so inconsistently from one team to the next. Project management also keeps track of various metrics, but there isn't a strong sense of consistency. Most people here would tell you that we probably don't track anything.

I'm interested to know if anyone "out there" has tried this technique with a development team of 40+ people.

IME, timesheeting is cumbersome: especially with dynamic projects, a lot of effort is made structuring and restructuring project billing trees to keep up with changes. Alternatively, you end up with categories that are too broad to offer tracking of any meaningful granularity.

I have found that story _base_d requirements capture gives people a common unit of work against which they can record time spent. Each story needs to be coarsely defined, achievable in a reasonable period (eg., less than a week) and executed through completion. With a lightweight story repository (like xPlanner - www.xplanner.org), team members can track time worked per each requirement, needing only to record this time with the completion of the story. It isn't burdensome time recording, it yields reasonably good accuracy in where time is spent and the actual cost of development, and variance of actual v estimate. It's worked in large departments and small teams.

Of course, it needs to be valued in the environment: if not, it'll be difficult for it to take root. You should be able to model this on a specific project, but it isn't likely to be durable beyond that team without organisational commitment.