Is there any recommended practice for how frequently code quality metrics should be reviewed by the team? I'm not sure how often should we be conducting a review of code quality metrics to look for potential issues that need to be addressed. We are working in Scrum sprint cycles, but I don't know if Scrum provides any advice?

Should it be reviewed daily, weekly, end of every sprint or what?

I'm thinking here of code quality metrics such as cyclomatic complexity, etc.

4 Answers 4


From a technical standpoint, code metrics should be baked into your test-driven development (TDD) or acceptance testing, preferably in an a fully-automated way. However, from a Scrum perspective, the framework is not prescriptive.

The correct framework perspective is that gathering and checking your current code quality metrics should be part of your Definition of Done. Reviewing the usefulness or accuracy of your metrics should be an ongoing part of your inspect-and-adapt cycle, which means:

  • Any impediments related to metrics that are raised during the stand-up should trigger a review.
  • Your current processes (including code quality metrics) should be reviewed during each Sprint Retrospective, provided that the issue fits within the time box and you don't have higher-priority process issues to discuss.
  • At any time, work related to your code quality metrics can be added to the Product Backlog for prioritization by the Product Owner.
  • 1
    Just to clarify: Adding it to the Definition of Done implies that developers check it (at least) whenever they finish a story. With sensibly small stories this means metrics are checked often. This is the only practical way to keep the effort required for improving the metrics at bay.
    – Sven Amann
    Commented Sep 25, 2014 at 7:36

This may not be an industry standard, but instead of measuring quality we're preventing it from decreasing. We simply do not allow programmers to commit anything to the master branch, unless it passes all quality checks. For example, cyclomatic complexity, which you mentioned. No programmer can merge anything into master branch, if his/her code has complexity higher than 5.

These two articles explain this approach in more details: Master Branch Must Be Read-Only and Strict Control of Java Code Quality


In my experience metrics are not a very reliable tool to gauge code quality. They are useful to a certain limited extent, if used as an indicator rather than an absolute measure. And they can cause even more harm if used without thinking or overzealously.* Ultimately only the expert developers familiar with the code can assess its quality. So I wouldn't spend an inordinate amount of time trying to "perfect" automated metrics - IMHO team members' energy is probably more efficiently used to fix blockers or work on value generating tasks instead.

Once they are set up and tailored to our needs, I prefer to use criteria similar to what @yegor256 describes in his answer. IMHO it may be enough to do a full review of the metrics a few times a year. I would rather look at it from the other end of the pipe: whenever we find a code defect (in the broadest sense), inspect how it could have been prevented. If we find that better code quality metrics or different evaluation criteria would have prevented it, change the rules accordingly.

* Recently in one of our projects, higher management requested that all issues brought up by an automated code quality metrics tool be fixed. And the task was given to a junior developer who completed it to the letter... The end result was a stinking heap of mysterious bugs all over the codebase (mysterious until we realized their source, that is).


Some metrics like "function cyclomatic" should be checked and alerted on each commit, as they might be harder to fix later on, but release quality metrics such as "no commented out code" can be left to code review on version delivery.

We use Sonar CI for simple daily auto-inspections, and ProjectCodeMeter for end of sprint (release) code reviews.

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.