I'm working on a task to create a quality metrics for our development process.

I have come across Test metrices and other size, complexity related metrices. But, I need to know if there's any metrics that could help find the risk associate with the business feature w.r.t to it's development/implementation, the amount to time that feature may need to finish by the person developing the feature etc.

There are no. of metrics that could be calculated once the feature has been implemented. I'm looking for something that could help the team before the implementation starts.

  • What exactly do you mean by "risk associate with the business feature"? Commented Nov 10, 2020 at 15:54
  • When the requirements come in, we need to analyse certain attributes to make sure if the feature would cause too much work effort, or if it's worth giving that much time to that feature or may be what measurable impact that feature will have. To me, it looks like a subjective measure but I want to discover if there are ways to have quantitative measures to answer these questions. Commented Nov 11, 2020 at 23:17

2 Answers 2


BDD- Behavior Driven Development

You define the working requirements of the software as automated tests.
Another term I enjoy using is executable specification that cannot be out of date if it passes

They initially fail as there is no code. The metric value starts at zero out of (say) five, so it is at 0%.

You write the code and they pass. The metric goes up.

If you have 5 initial requirements and 2 are done then the metric says you might be 40% done.
Although in reality the last task might be 80% of the work, etc. This is because making accurate predictions is quite easy. Except for those about events in the future.

Unfortunately unless you are doping waterfall or mini-waterfall, in Agile environments this should be happening constantly not in a waterfall way. In other words new requirements (stories) are coming in constantly.

You could try measuring your backlog but most backlogs just have the same shape - steep curve initially that flattens over time as the backlog just becomes an artifact and parking place of avoided work and technical debt and not a true source as the main feed into application development. This can be avoided by deliberate actions (I've done that) but that is a maturity many shops do not achieve. It takes a team effort and full ownership of the development process by the people doing the work.


Equivalence partitioning or equivalence class partitioning (ECP) is a software testing technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test cases that uncover classes of errors, thereby reducing the total number of test cases that must be developed. An advantage of this approach is reduction in the time required for testing software due to lesser number of test cases.

With that you can derive the number of test cases that actually need to be ran and using historical data you can estimate the overall lift. You might also be able to assess risk by seeing if something is likely to be called in a typical user flow, for example.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.