In the context of metrics you might find these scrum metrics (or their adaptations) also useful

http://www.pragmaticsw.com/Newsletters/newsletter_2008_07_SP.htm
http://www.danube.com/docs/Scrum_Metrics_for_Management.pdf

Wonderful question, since it actually refers to one of the lesser talked about aspects of agile methodologies. Especially in the context of extreme programming and test driven development, the customer is anyway a part of the user stories definition and it is possible to publish the test case execution and code coverage execution as well.

This allows the customer to
a) Participate in the lighweight requirements specification
b) Review the test case definitions and how extensive and comprehensive they are, and
c) Code Coverage reports – to verify how extensively the tests cover various aspects of the code and
d) Test case execution reports – how many test cases succeeded and failed.

The big difference is that while agile development methodologies tend to emphasize metrics at the end points, they try to be very process light on the stages in between.

When some one says that we are using RUP or any other process I know what kind of data I should expect from them to prove their capabilities. Audit reports and other measures. Even though Agile do encourage people to measure these data, but due to its inherent nature or due to misconception that Agile means “Lets get this damn thing working and done”, measurements/design/audits etc are not done. So what is a way to make sure that the team I am hiring/contracting/outsourcing to has the capabilities? This is where Agile Process Maturity comes in to picture. Though I dont agree or endorse any of the views of Scott, but I would like to have a methodology or framework which can certify and control to some extent about maturity and repeatability of a development team.

Also being people centric is good, but still we would need a method to make sure people are replaceable too.