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: