Your team has been working hard for two weeks, but as the sprint end nears, stories start to pile up in the “Waiting for Review” column.
“Well, the ticket is done, I’m just waiting on Michele to review the code.”
“Oh, I pushed that into the review column last week, but I couldn’t get anyone to approve the pull request.”
On larger teams, code review can be a major blocker to getting a story to “done.” Sprint estimates and velocity suffer because stories get stuck. And product owners start to feel like the engineering team isn’t performing or working hard.
I’ve seen some version of this on almost every engineering team I’ve worked on. And what finally fixed it was applying a concept already familiar to engineers.
Agree, as a team, to set a Service Level Agreement, or SLA, for code reviews.
SLAs are common in contracts with hosting providers and other dev infrastructure. Their real value is getting agreement, up front, on the expectations between two parties for responsiveness and uptime.
The team agrees to an SLA for code review where each team member commits to resolve a code review within a certain window of time. For example, if I open a pull request and request a review from Michele, we’re both agreeing to have the code review complete and pull request merged within 1-day. Our team SLA for code review is 1 Day.
Over time, you can track your team’s performance against this metric, and even review it as part of your Sprint Review. If certain individuals are often violating your team SLA, then it’s a topic for discussion in your next 1-on-1.
Eliminate waiting waste by prioritizing code reviews with SLAs. Has this worked for you? Or have you had success with something else? Drop me a line, I’d love to hear more.