General Musing

blaze your trail

Code Review in SCRUM? #xp #agile #mathematics

with 7 comments

Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.

How a code review estimate is done now?

Using the research done by Cisco Systems[1][2] I came up with an algorithm to help with the estimate, in the algorithm l is the number of lines of code and t is the average time spend 60-90 minutes – it should probably be closer to 60 than 90 minutes – for each of the blocks of 300-400 lines of code b to be reviewed. And a reviewer can be expected to find 70-90% of defects in the reviewed material. This algorithm naturally ignores that the real algorithm it is a polynomial equation and almost certainly a NP problem. This linear equation is merely a guideline which makes it possible to better estimate the amount of time spend on the code review.

Read more articles on , or

This means that for a project with 12 kloc – 1000 line of code – the equation would yield an answer of 30 hours (t) for the review. Naturally the Cisco Systems study also states that a code reviewer must rest between reviews, otherwise the review would exceed the number of lines and time. Although the research didn’t produce a clear amount of time that should be spend on the review, it is clear that this should be a significant amount to encourage continuing effectiveness of the reviewer. From a time management perspective I would advise spending at least 1/3t or 1/2t in a task which doesn’t involve reviewing code. Meaning that review time should be multiplied by 1.333R or 1.5.

How it is done in SCRUM?

In SCRUM the code reviews are more often done in conjunction with the development, although the practice of reviewing is the same the code is reviewed as User Stories are delivered. This means that the code is reviewed shortly after it is produced, meaning that the developer who wrote it has a better memory of what he did and why he did it. A review cycle should probably take about 1.333R of the time of writing the code.

Continued refactoring of code by developers done in SCRUM teams allows for more review of code to be done outside of review cycles.

How it is done in XP?

XP is code reviewing and code testing on crack, Pair-Programming, Pair-Negotiation, Test Driven Development and Continuous Integration allow code reviews to be performed at as the development is happening. Additional external code reviews will still pick up issues, although the defect density will likely be lower than in traditional development methodologies.

Other best practices

The XP and SCRUM methodologies to review don’t negate the fact that coders should continue to annotate all difficult to understand code and should allow for code readability over optimization in all but the most extreme circumstances. And naturally check lists should be make to ensure that any cases which can not be expressed in automated tests are covered – such as certain memory management aspects. Lastly finding a defect is fantastic and should be awarded, every defect found should be treated as a magnificent step to creating truly excellent software.

Any developer whose code was found to contain a defect should know that statically 1 kloc contains between 15 – 50 defects[3], also known as the defect density, it is to be expected that code contains errors, programming is an NP problem.

  1. Best Practices for Peer Code Review
  2. Best Kept Secrets of Peer Code Review
  3. Bugs per lines of code

Written by Daniël W. Crompton (webhat)

October 24, 2011 at 3:35 pm

Posted in programming, risk

Tagged with , , , , , ,

7 Responses

Subscribe to comments with RSS.

  1. I certainly agree that code reviewing is important, though I’m a bit uneasy about your closing sentiment. Perhaps just a wording choice, but it seems to imply the programmer need not be rigorous simply because, statistically, they’ll produce bugs anyway. I still think it is valid for a programmer to try and produce zero bugs and should always do a personal post-mortem on their defects. That is, ask themselves why they coded a particular defect and think of how to avoid it in the future.


    October 25, 2011 at 9:07 am

    • My idea was not to say that programmers need not be rigorous, they don’t need to be concerned about having made a mistake – and certainly shouldn’t feel bad about any bug discovered in their code.

    • It’s true that a programmer should strive to produce bug free code, but it is impossible to accomplish this. There will always be bugs. I don’t think that Daniel was suggesting that coders don’t need to ensure that their code is clean though…

      Now about the 15 to 50 defects for each kloc, I think the range is logical for a first draft of code. The second pass these numbers should be substantially lower…

      PM Hut

      October 26, 2011 at 10:42 am

      • The defect/kloc ratio is based on a first draft, and as I stated in the text:

        … a reviewer can be expected to find 70-90% of defects in the reviewed material.

        webhat/redhat (@webhat)

        October 26, 2011 at 12:54 pm

  2. Code review is essential in software development as it ensures the quality of the product. Though not all developers/programmers are the same, some (maybe unconsciously) are being biased specially when doing code testing and will likely to overlook other things which only a reviewer can see it. Reviews can be done as desktop reviews or through formal code reviews. In any case, this process helps us spot defects and contain them as early as possible.


    October 16, 2012 at 4:00 pm

  3. Hello would you mind letting me know which web host you’re working with? I’ve loaded your blog in 3 different web browsers and I must say this blog loads a
    lot quicker then most. Can you suggest a good internet hosting provider at a honest price?
    Thank you, I appreciate it!

    voyance en direct

    July 14, 2013 at 6:36 pm

Please Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: