We have recently moved to a scrum process and are working on tasks and user stories inside of sprints. We would like to do code reviews frequently to make them less daunting. We are thinking that doing them on a user story level but are unsure how to branch our code to account for this.

We are using VS and TFS 2010 and we are a team of 6.

We currently branch for features but are working on changing to branching for scrum.

We do not currently use shelvesets and don't really want to implement if there are other techniques available.

How do you recommend we implement code review per user story?

5 Answers 5


It depends on the nature of the user stories.

It can be effective to create a branch for each user story, progress on different stories are visible, they can be passed around if needs be, if stories aren't completed in the sprint then the progress can stay in the branch for the next sprint. Final reviews can then be performed at the end of a user story in the use story branch and merged in if the code is up to standard.

To work in the manner stories need to be finely grained to prevent unmanagable merge tasks at the end of a sprint. Small stories will allow a steady update of the dev branch through the sprint that devs working on other user stories need to constantly pull from (basic VCM).

This does create process overheads having to create and merge branches constantly which in some cases can be resolved with automation scripts but the team still needs to be very comfortable with the VCS.

At the end of a sprint you merge your dev branch into integration/production etc.

I have also worked in teams where everyone works off one dev branch, on completion of a user story the code is pushed to that branch for review and testing and if someone pushes something that breaks the dev build they have to get the team beers in.


The most effective way to review code is to stand up, find someone, and ask them to come over and discuss the code you have just developed.

Don't use a tool unless you cannot find someone to review your code locally.

You can avoid code reviews altogether by pairing.

  • I was wondering when someone was going to mention pairing. Between that and unit testing you get a lot of review.
    – JeffO
    Mar 8, 2011 at 21:39
  • I read this as "stand up, fire someone, and ask them to come over and discuss the code you have just developed." Thanks for making my day. Sep 4, 2012 at 15:56

Is everyone on the team local? If so, just ask someone to come over and have a look before the code is checked in. Not local? Fire up your favorite screen-sharing program and call someone. I personally do this often. Sometimes I do it just to say "Hey, look what I did!"

I much prefer this style of ad-hoc code reviews to the style where someone is standing up and presenting their code to the team. Ad-hoc reviews can give you many (all?) of the benefits of pairing without the awkwardness. Also, your "reviewer" is more likely to ask questions and suggest improvements in an informal, one-on-one setting.


I believe code review is not a formal part of SCRUM, yet revisions are an independent tactic to achieve quality and improve your projects/team.

So, you would use SCRUM (or other agile development methodology) to ensure/improve PROJECT quality and keep on schedule. Also, a good tactic is to do product revision (not code) indepently from your normal QA/testing tasks. If this activity could be done in front of your team/partners/clients/audience it will be better.

You should use code (or other specific) revisions mainly to improve your TEAM, expecting results on a middle/long term basis. This will affect your PROJECTS, but in the long term as a product of your TEAM improvement.

So, to answer your question, i believe you are trying to push too much from SCRUM, and you should better consider revisions only as it is.

  • Scrum doesn't say or advise anything regarding schedule. It does expect you to deliver value on a regular basis. It also provides moments in which you can inspect and adapt your process so as to get better (better not necessarily meaning faster). Mar 8, 2011 at 21:36
  • Yes, Scrum does not state making a full schedule as part of it. Still, i meant "planning" when i refered to schedule, planning meaning that your client expects some value in a given time, so they could perform the exchange between money v/s value (if you consider that you are providing develop/programming services).
    – Ron-Damon
    Mar 8, 2011 at 21:42
  • In that matter, your client should have a budget to spend in a given time (to pay you, for instance) and he may have a schedule to attend to. I work as a service provider, that's why i cannot left this fact aside.
    – Ron-Damon
    Mar 8, 2011 at 21:50
  • Contracts aside, Scrum teams deliver value not services. We develop/program as a means to deliver that value. Mar 8, 2011 at 21:59
  • I don't believe you could separate the terms "value" and "service" friend. I also believe this is very off-topic now.
    – Ron-Damon
    Mar 8, 2011 at 22:14

Isn't it obvious to do code reviews before checking in your code?

TFS doesn't work like GIT, so whenever you check code in to a branch or the trunk, it is available for everyone.

This means the review should happen at check-in so bad changes aren't propagated to everyones working copy.

  • I would think that, in general, unit tests are what would prevent bad changes. Mar 8, 2011 at 19:59
  • @John Saunders: Consider code reviews as another type of unit test. Mar 8, 2011 at 20:00
  • @Gilbert: I could do that, but then I wouldn't get their benefit for regression testing. I'd prefer to spend the time on writing more and better unit tests. Mar 8, 2011 at 20:02
  • @John Saunders, @Gilbert Le Blanc code reviews are performed by another developer, unit test are generally done by the original developer, the new perspective can be vital.
    – whatsthebeef
    Mar 8, 2011 at 20:08
  • I've had good luck with unit tests (the test lists are agreed ahead of time) and automated code analysis, possibly combined with a style analysis tool like StyleCop. But then, I don't often work with junior developers. Mar 8, 2011 at 20:10

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.