In my opinion, metrics around test cases and requirements are not the way to go for Agile testing. It is quite easy to add a lot of simple test cases that do not add that much value, but which could alter the metrics positively.
I personally find the following metrics most useful in Agile testing:
Root Cause Analysis
Root Cause Analysis shows what caused the bugs that are still in the system and why they have escaped testing.
Personally, I also prefer into dividing the escaped bugs into whether it would have added enough value versus costs if they would have been found earlier. A bug that only happens at one customer because their setup if very specific could have only been found earlier if you test all oddities of all setups of all customers. That is not worth it due to its costs versus the benefits (i.e. the bugs that would be uncovered due to extra testing). This gives two categories:
- Bugs that should have been found earlier
- Bugs that should not have been found earlier
After you have done a Root Cause Analysis into those two categories, you can show whether the test process located more bugs with the highest priority versus fewer bugs with a lower priority (rather find a functional problem than a textual inconsistency). Do note that the cause of bugs not being found early enough is not always a blame to the test team, f.e. it could be a requirements-issue (customer expected something else than is delivered).
This shows that you perform Agile testing as expected: assure the quality with most certainty in least amount of time (as time is almost always the limiting factor).
Amount of open bugs
You can also keep a graph of the open bugs at any moment in time. Ideally you measure this into priority categories. Critical bugs that need fixing within days are more important than textual inconsistencies. Note that it is not the main priority of the test team to keep the amount of bugs as low as possible, but it is a team-effort (developers need to fix them in the end).
Bugs per category
You could also keep track of the amount of bugs per category, where you can define categories as you see most fit. You could use categories like performance, security, functionality, etc., or based on components of your product (for Stack Overflow: questions & answers, search, profiles, etc.). This gives a good insight into what categories need more attention, from either testing (if a lot of security bugs arise, you should make time early so that less and less escape the test process) or from developing (to fix the bugs).