2

As a metric of software quality, we calculated the ratio in the Title.

The value of this KPI should have the following meaning:

  • 0 (0%) = no work on bug, this means that all the time spent on the project was used for new features, great!
  • 1 (100%) = working only on bug, this could be a legacy project, where there are no new features so all the time spent on that project is about bug fixing&testing;
  • 0.5 (50%) = half of the time is spent on bug fixing&testing, this could be a problem in a normal project.

So the question is: in a normal project (not legacy) what could be a healty value of that KPI?

Someone told me 33% but I cannot find any literature about that value.

Improve this question
7
  • 1
    Context dependent. Also depends on automated testing and BDD. Do you mean escaped defects to Production or do you mean pre-release defects?
    – Venture2099
    Commented Feb 6, 2017 at 18:48
  • Your metric assumes time not spent on bugs means there are no bugs. This is flawed on its face.
    – Todd A. Jacobs ♦
    Commented Feb 7, 2017 at 3:28
  • @Venture2099 both, but mainly pre-release ones.
    – greenkey
    Commented Feb 7, 2017 at 8:46
  • @CodeGnome why you think it's flawed? I know it's almost impossible, it's only an example.
    – greenkey
    Commented Feb 7, 2017 at 8:46
  • 1
    @greenkey: I can reach the 0 time metric by simply ignoring all bugs that come in. In that way, no time spent on fixing bugs does not indicate that there are none. Just that nobody worked on them.
    – Bart van Ingen Schenau
    Commented Feb 8, 2017 at 13:41

1 Answer 1

Reset to default
1

This really depends on the methodology you are using, the expertise, experience and the rigor of people you are working with. The time you allocate for the development matters as well, I have been working with people who tends to deliver on time even if it's not 100% completed.

That being said, I can relate to this KPI and based on the few hundreds small software development projects I have been involved with, this 33% metric seems quite high but plausible. We try to target a 15%-20% in my team but that required to enforce the ownership of the development team on their projects.

Improve this answer
2
  • 1
    Thanks for the answer. It seems there are no official documents in the literature, it's more something that you monitor and try to decrease.
    – greenkey
    Commented Feb 7, 2017 at 8:53
  • Well...technically no. I want automated test coverage to identify more bugs prior to production. That indicates it is working.
    – Venture2099
    Commented Feb 7, 2017 at 9:27

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.