A GDC project manager states his project status in the PMO meeting, “# of report design documents are in process, # of report design documents are completed, # of report design documents are not started… Regarding the quality, # of design documents passed review…”
‘Waterfall~ Waterfall~‘ other PMO members sing for him with the sarcasm – Maybe we are unkind, but who can ensure the feature’s quality when it’s just something in documents?
The GDC project manager tries to find a metrics the design review pass rate to measure the quality – that’s good. But if really wants to know the quality status of the project, the answer is still to follow AGILE – deliver SHIPPABLE features iteratively.
The below metrics can be adopted to indicate the quality.
- Unit Test Coverage and Pass Rate – UT usually is conducted by developers. From my view, the UT metrics are not only indicating the quality of code, but also indicating the maturity level of a team. The cost on UT is a sort of prevention instead of rework, that’s why UT skill is the basic skill for developer. But, we should not to do UT just for the metrics.
- System Test Coverage and Pass Rate – Some projects have dedicated QA team to conduct ST, some project don’t – developers conduct ST by themselves. Each has the advantages and disadvantages – I don’t want to expand the topic here but personally I prefer the latter. For the metrics itself, we need pay attention to the Coverage metric, it should count all the running features instead of the features for present Sprint. Nobody wants to see the new features break the existing features!
- UAT Coverage and Pass Rate – They are the real metrics indicating the quality. But to be honest, so far I have not experienced once that clients conduct the UAT right after the Sprint. Usually there will be a UAT phase, actually, it’s a UAT plus Bug Fixing phase – during that period, there is no new features being delivered – from the story points perspective, it’s ZERO!
I don’t put any metrics for Integration Test because for any features in each Sprint, making sure them can be integrated without any impact to the existing features is the definition of done of those features. And there are other metrics can be introduced, such as the Performance Test Metrics, User Experience Test Metrics and so on. It’s depends on your project.
By the end, I want to say to follow Agile may not resolve your project quality issue – but it can tell you the real quality status!
And, I don’t want to hear others sing the “Waterfall~” song for me even he is Pavarotti 🙂
