liveBook · Manning

Code review time

As explained in "Looks Good to Me"

The amount of elapsed effort or duration required to examine and evaluate a proposed code change.

Code review time is the duration needed to examine and evaluate a proposed change. Smaller, atomic pull requests reduce it by limiting files, lines, and cognitive overhead. section 9.2.2

Teams can make review time visible and protect it by:

  • Adding estimated review time to a story or listing review as its own task. section 9.2.2
  • Reserving specific review days or hours, or reducing planned sprint work to create capacity. section 9.2.2
  • Pairing review-time metrics with contextual discussion instead of using them to justify cutting corners. section 9.3

Making review capacity explicit

A team plans review time alongside feature work, keeps changes small, and reserves dedicated hours when normal delivery pressure would otherwise displace reviews. section 9.2.2

How "Looks Good to Me" covers it

How deep it goes
Explains how smaller PRs reduce review time and lists planning mechanisms, but stops short of defining a measurement formula.
Examples
Uses smaller atomic PRs, estimated review time on stories, dedicated review hours, and a 20% technical-debt allocation.
What you can do after
Evaluate review efficacy with contextual metrics and reserve capacity for reviews through planning or dedicated time.
How it connects
Connects review time with pull requests, PR size, code churn, review participation, technical debt, and feedback culture.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of "Looks Good to Me". The section links point to the parts of the book it draws on.