Peer Review Checklist

[Daniel Pettet]

Why execute Peer Reviews?

A review from a peer (eg, another developer) is essential to help reduce human error and close quality gaps. Nothing is perfect and that is especially true for configuration. Spotting issues as early as possible reduces risk and further, more expensive cost down the line.

Avoiding poor configuration and solutions is the best way to maintain a healthy ServiceNow platform.

Using the Peer Review Checklist

Peer reviews during story execution are best done in the "work in progress" phase. When the main developer of the story considers the work to be complete and the acceptance criteria to be fulfilled, a (scrum) task can be created and assigned to the development group or another individual that can review the work. This task should include a link to the peer review checklist.

The task is considered done when the person executing the checklist has documented findings for consideration OR has indicated that no issues were found during review.

The output and findings of the review are documented in another task and assigned to the main developer of the story. This task can be considered complete when the developer has reviewed, understood and actioned the output as applicable. This may include:

• Revising issues found that would violate best practices or compliance rules
• Fixing bugs that cause the acceptance criteria to fail
• Following up with the product owner or story requester to draft new stories or enhancements
• Reverting changes and cancelling the story. 

Sometimes the last option is the best course of action even if it is embarrassing that critical issues with the story requirements or implementation approach were not identified before the story was approved and set to "Ready". Consider that a better process or platform health friendly approach may be possible. See this as a positive proof that the peer review process is helping to catch problematic customisations.

Managing with Tasks

The following 2 tasks (mentioned above) are recommend to manage the peer review process. These are:

1. Perform Peer Review
2. Address Peer Review Feedback

These tasks can be generated with minimal effort via UI Actions or auto-created via a business rule. Using multiple tasks helps with transparency on progress and ownership and enables better auditing of peer reviews.

Be aware that quality takes time and introducing a peer review may increase story development time slightly. The reward for the investment is quality and overall reduced risk and cost. It shouldn't take longer than 5 minutes for simple stories to execute and no more than 30 minutes for complex stories. This is yet another motivator to keep stories simple and small. Eg, a story that can be completed in 1 day or less is fine. A story that takes more than 3 days should probably be split up. Following this guidance will ease review complexity and significantly reduce overall testing and revision time.

The Checklist

Below is a checklist that all teams can make use for any context including development, documentation or spike type stories. Place it with onboarding material for all team members to find. Expand on it to include company or team specific requirements. Include compliance checks as necessary. Ensure that all team members understand how to execute the checklist and why to use it as a guide.

Further Reading

The below resources may also help with refining the peer review for your needs:

• Technical Best Practices
• Performance Related Best Practices
• Naming Conventions
• Magic Numbers

[Maik Skoddow]

Hi @Daniel Pettet 

thanks a lot for that checklist. That would have been one of my next articles! But now I can save myself the work 🙂

Two questions:

1. Why didn't you present the checklist in the article? This way the checklist would get more visibility and no one would have to feel compelled to download a document first.
2. Would you like to link my fresh article regarding Naming Conventions? This topic I miss in your Checklist!

Kidn regards
Maik

[Daniel Pettet]

Hi Maik,

Originally I just wanted to provide the file without details on all the things in the checklist. One could consider this a starting file. I really want customers/teams to own the document and add their own checks as they see fit. Particularly if they have various compliance checks that should be made (which are often customer/region specific). If there's more feedback in this direction then I can also just copy the checklist to the bottom of the article.

I'll add a further reading section for naming conventions. I think it's a great asset to help all developers and drive consistency.

[Maik Skoddow]

Sounds great!

Just another hint: Please link "Magic numbers" to any website explaining that. I think a lot of developers never have heard that before.

[GTSPerformance]

We would like to humbly submit for the consideration of all, that our list of ServiceNow performance best practices be added to your peer review checklists.

Best regards, the ServiceNow Global Support Performance team

[Daniel Pettet]

Thanks for the tip! Great page. I've updated the further reading list and the checklist to link to that page.

[timsabaumckean]

@Daniel Pettet thank you this article was extremely helpful in assisting us migrating off Jira to ServiceNow's agile dev app.

Would the recommendation to be create a new scrum task type or to use an existing one for peer reviews? If an existing one, which one would you recommend? We've been using testing but that's merely because it has the ability to have a Pass/Fail field so we can report on how many times something has passed/failed peer review