Who picks up the code review? Let the board answer that, not the standup

"Right, the login thing. Is that finished?"

"It's finished, it's in review."

"Who's reviewing it?"

"Uh. Nobody yet."

"Sam, can you take a look?"

"Yeah. Probably today."

Ninety seconds. Every single morning, with the ticket number changing and nothing else changing at all. Nobody in that exchange learned anything about the login work. What actually happened is that a routing decision got made out loud, slowly, in front of six people who did not need to watch it, and it landed on Sam. It always lands on Sam. Sam is the person who says yes fastest, so Sam is the person the board quietly elected reviewer-for-life some time last spring.

That question does not belong in a meeting. "Who is reviewing this?" is a property of your workflow, in the same way that "which column does a finished story go in?" is a property of your workflow. If a card entering your review lane does not already know who owns it, that is a gap in the board, and you are paying for the gap in ninety-second instalments.

The board already knows the answer

Here is the thing that took us an embarrassingly long time to say plainly: the moment a story changes status is the moment the routing question has an answer. A card entering a testing lane needs a tester. A card entering a code review lane needs a developer who is not the one who wrote it. A card entering a "waiting on the business" lane needs the product owner. None of that varies per story. It is a fixed function of the lane.

So in Scrumpy, the lane holds the rule. Every story status has an optional "auto-assign on entry" setting, and when a story lands in that status the assignee is resolved right there, in the same operation as the move. You will find it in Settings, Team, in the "Story statuses" card: click the pencil on a status and it is the last field, a single dropdown with four options.

Four, and that is the whole feature:

Option	What it resolves to
Tester	Someone on the team holding the Tester role
Random developer (not original)	Someone holding the Developer role, excluding whoever built the story
Product Owner	Someone holding the Product Owner role
Original developer	Back to the person who built it

In prose, because that table is the kind of thing that gets flattened when this post gets syndicated: a lane can hand work to your tester, to a developer who is explicitly not the author, to your product owner, or back to whoever wrote it in the first place. Nothing else. There is no rule builder behind it and no conditions to write.

The part that makes this useful out of the box is that the default development board already wires it up. A new team seeded with the development preset gets seven lanes on the board plus one off it: New, Development, Testing, Code review, Stakeholder, To be released, Released, and a "Won't do" that lives off the board. Testing auto-assigns to the tester. Code review auto-assigns to a random developer who is not the author. Stakeholder auto-assigns to the product owner. To be released hands the card back to the original developer, because whoever built the thing is usually the person who knows whether it is safe to ship. Every one of the four options is attached to a real lane on day one, which is unusual: most tools ship the capability and leave you to discover it.

There is one more piece, and it is the piece that makes the review routing possible. Independently of any auto-assign setting, moving a story into a lane flagged as "in progress" assigns it to whoever moved it, records that person as the story's developer, and stamps the start time if it was not set. That recorded developer is the memory the board uses later. When the card reaches Code review, the exclusion of the author is not a guess about who wrote the code, it is a lookup of who dragged it into Development.

Why this deletes a whole category of standup chatter

A standup is meant to be a coordination checkpoint, not a queue-management meeting. The problem with the "who's reviewing it" exchange is not that it is long. It is that it is a decision, and decisions in standups expand: someone negotiates, someone else offers to take it instead, and you are four minutes in on a topic with one correct answer.

When the lane assigns, the decision has already happened. By the time you walk the board, the review column shows names, not question marks. The conversation you have instead is the useful one, which is about whether anything is stuck, and stuck now looks different: a card sitting in Code review with a name on it since Monday is visibly a problem, whereas the same card with nobody on it was just ambient background noise.

The person picked also gets told. Assignment fires an in-app notification that arrives live over the websocket rather than an email, and it deliberately does not notify you when you assigned the card to yourself. So the reviewer finds out at the moment the card moves, which is hours before the standup where they would otherwise have found out.

And it kills the Sam problem, which is really a social problem wearing a process costume. Sam ends up with every review because volunteering is faster than negotiating, and once that becomes the pattern nobody has to decide anything ever again. A lane that picks does not know who is agreeable.

Jira and GitHub can do this too, and here is the honest difference

I want to be careful here, because "our tool has a feature" is not an argument, and both Jira and GitHub have shipped comparable things for years.

Jira has a native, non-automation route. In a team-managed project you can add a workflow rule that assigns work on a transition, choosing from four targets: the reporter, the current user, nobody, or one specific named person. Atlassian's own documentation for it uses exactly the example in this post, assigning to the QA champion when work moves to review. In a company-managed project the equivalent is a workflow post function, "Assign to Current User", "Assign to Reporter", "Assign to Lead Developer", or an Update Work Item Field step, and those require a Jira admin plus a workflow publish cycle.

Anything smarter than that lives in Jira automation, and it is genuinely more capable than what Scrumpy offers. The "Assign work item" action can assign to a user in a role or a group, and when you give it a list of users it will distribute by Balanced workload ("each user has an equal number of work items"), Random, or Round-robin. It can be gated on JQL. That is a real superset of four dropdown options, and if you need "assign to a senior engineer only when the story is flagged and in the payments component", Jira does it and Scrumpy simply does not.

The difference is what you pay for the capability, in two currencies. The first is construction: a Scrumpy team changes one dropdown on one status, and a Jira team builds and maintains a rule, which only project or global admins can do. The second is metering. Jira automation is billed by rule runs per month, and the live numbers as of this writing are 100 runs a month on Free, 1,700 on Standard, 1,000 per user per month on Premium, and unlimited on Enterprise. Worth knowing: the widely repeated line that single-project rules are exempt from the limit is out of date. Atlassian changed that in November 2023, and single-project rules now count like everything else. So an auto-assign-on-transition rule on a Free instance is spending from a budget of 100 successful runs a month, which a team of six moving cards through a review lane will burn through in a fortnight.

GitHub's version is reviewer-shaped rather than assignee-shaped. CODEOWNERS requests a review from the owners of the changed paths, which is a genuinely better signal than any board can produce, because it routes on the actual diff rather than on a lane. It does not set the assignee field, it requests review. Two constraints are worth checking against your own setup: CODEOWNERS is available in public repositories on the free plans, and in private repositories only on Pro, Team, Enterprise Cloud or Enterprise Server, and the same visibility-crossed-with-plan shape applies to the protected branch option that requires code owner approval. Then, separately, org teams have code review assignment settings with two documented algorithms, round robin (least recent request) and load balance (fewest outstanding requests, aiming for an even count over 30 days). Those are org-team settings, so they do not exist on user-owned repositories, and private repos need Team or Enterprise.

Two things I will say for GitHub over what we do. Load balance actually counts outstanding reviews, and members who set their status to Busy are skipped. Scrumpy has neither. And one thing worth flagging in the other direction: GitHub does not document any setting to exclude the pull request author from auto-assignment, whereas "not the person who built it" is baked into the Scrumpy option, which is the one guarantee you actually want from review routing.

Also: CODEOWNERS routes a diff, a board routes a story. If your review step is a pull request and nothing else, CODEOWNERS is the better instrument and you should use it. The board version earns its place when the review lane is about more than code, when it is the step where a second person confirms the story meets your definition of done.

Where this is the wrong answer

I went into this thinking the value of random reviewer assignment was fairness. It is not. Random is bad at fairness, in the specific sense that it has no memory: the selection is a random pick among eligible people, not a round robin, so nothing tracks who reviewed last or who has four reviews open already. Over a few hundred cards it evens out. Over one sprint it absolutely does not, and you can draw the same person three days running.

What it is actually good at is deleting the pause. That is a smaller claim and a truer one, and it means most of the failure modes are about pretending the pause was the only problem.

The holiday one is the plainest. Scrumpy has no concept of availability. No away flag, no working hours, nothing. If someone holds the Developer role and is on a beach, the board will still hand them a review, and it will sit there looking assigned, which is worse than sitting there looking unassigned. There is no clever fix inside the feature: either you move the role off that person for the week, or you accept that a human notices and reassigns. If your team takes long absences and nobody reads the board daily, do not turn this on for review lanes.

Then there is the pool problem, which bites teams of exactly the size this post is aimed at. The pool is the set of members whose role is Developer, and a member holds one role, not several. So if your team of six gave two people the Tester role and one the Product Owner role, your developer pool is three, and excluding the author leaves two. With a pool of two, excluding the author leaves exactly one person, deterministically, forever. You have then built a rather elaborate machine that says "Sam does it". Before enabling this, count how many people actually hold the Developer role, and if the answer is two, you do not have a routing problem, you have a capacity problem.

A related gap in our own implementation, which is worth saying out loud because you will hit it: the "not the original developer" exclusion depends on that developer having been recorded, and it is only recorded when a card passes through an in-progress lane. Drag a card straight from New to Code review and nobody was ever stamped as the developer, so the exclusion has nothing to exclude and the author can be handed their own review. Similarly, "assign back to the original developer" has nothing to point at. And if literally nobody on the team holds the role a lane is asking for, the assignee resolves to nothing and the field is written as empty, which means it clears whoever was on the card. A card that was assigned to you can come out of that move assigned to no one. Configure the roles before you configure the lanes.

Last one, and it is the least mechanical. Random assignment distributes the request. It does not confer context. On a team where the codebase is genuinely shared, that is fine and the review is useful. On a team where one person has owned the billing integration for two years, a random reviewer on a billing change produces a rubber stamp, which is worse than no review because it looks like one. I would not auto-assign code review on a team with strong ownership boundaries. I would auto-assign the testing lane, where "the tester looks at it" is true regardless of what changed, and leave review routing to the humans who know which module just moved.

Turning it on

The honest scope of this feature is one dropdown per lane, four options, no conditions. That is a deliberate ceiling, not a roadmap gap: the moment it grows conditions it becomes a rules engine, and a rules engine is a thing you maintain rather than a thing you set.

If you want to try it, do not configure all seven lanes. Pick the single lane where the pause happens most often in your standup, which for most teams is review or testing, and set that one status. Give it a sprint. If the question stops coming up in the morning, you have your answer. If it comes back in a different form, "who is actually looking at this one, though", then routing was never the real problem and you have learned something more valuable than a settings change.

The board is the shared picture of who owes what. It should be able to hold that picture without help, and it definitely should not need a meeting to keep it accurate.