Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /optimization/code-review-scheduling.md or by requesting this URL with the header Accept: text/markdown.
Planning technique

Code Review Scheduling, Explained Properly

Review is where finished code waits. Here is how to schedule it, and a straight answer about Orangescrum: we are not a code review tool, we manage the work around one.

Start free trial See all features

What is code review scheduling?

Code review scheduling means treating review as planned work with a place in the schedule, rather than as something people squeeze in around their own tasks. In most teams review is the largest source of hidden delay: the code is written, it sits, and the change is not really finished for days. Scheduling it means agreeing who can review what, reserving capacity for review in the sprint or the week, setting a response time the team commits to, and making a waiting review visible on the same board as everything else. The review itself still happens in your code host. What is being scheduled is the human attention it needs.

Where review quietly stalls delivery

  • Work is finished but not doneA change is complete on Monday and merged on Thursday. Nothing was wrong with it. It simply waited, and the sprint burndown says the team was slow.
  • One person reviews everythingThe most senior engineer becomes the queue. Their own committed work slips while they clear other people's, and nobody plans for the hours it takes.
  • Review capacity is never in the planThe sprint is filled with new work as if review were free, so reviewing happens on top of a full commitment and gets done last, or badly.
  • The queue is invisible at stand-upReviews sit in a separate tool from the plan, so the team discusses tasks while the actual blockage is a list of open changes nobody has opened.

What Orangescrum actually gives you

Real features, named. Nothing here is an algorithm that decides for you.

Give review its own columnA dedicated In review state puts waiting work on the same board as everything else, so the queue gets discussed instead of assumed away.Kanban boardDefine what in review really meansSet the states your team actually uses, such as In review, Changes requested, and Ready to merge, so a status reflects reality rather than a default.Custom statusesReserve capacity for reviewingPlan review as work inside the sprint rather than as a free activity, so the commitment the team makes is achievable with the review load included.SprintsSee who is carrying the queueA workload view shows the person who is both delivering their own work and reviewing for everyone else. That person is usually the bottleneck.Workload managementShow build status on the work itemIn Self-Hosted, Jenkins pipeline status appears against the work item, so a reviewer can see whether the build passed before opening the change. Self-Hosted only.Jenkins integrationTrack what review keeps findingLog recurring issues raised in review as defects linked to the work, so a pattern becomes visible instead of being rediscovered every time.Defect tracking

How to schedule review properly

  1. Decide who can review whatWrite down which people can review which areas. If the honest answer is one person for a whole area, you have found a risk as well as a bottleneck.
  2. Agree a response time and say it out loudSomething like: a change waiting for review gets a first response within one working day. Without a number, review is always someone else's problem.
  3. Put review on the boardAdd an In review status so waiting work is countable. A board with eight items in review and two in progress tells you exactly what to fix.
  4. Book the capacity in the sprintEstimate the hours review actually takes and hold them back when the team commits. A sprint planned at full capacity has no room to review anything.
  5. Look at the queue before you look at new workAt stand-up, clear the review column first. Finishing work already written is nearly always worth more than starting something new.

What Orangescrum does not do here

Orangescrum is not a code review tool. There is no diff view, no pull request, no inline comment on a line of code, and no approval gate on a branch. Reviews happen in GitHub, GitLab, Bitbucket, or wherever your code lives, and that is where they should happen. Orangescrum handles the planning around them: the status that says a change is waiting, the capacity set aside for reviewing, the workload view that shows who is carrying the queue, and in Self-Hosted the Jenkins integration that puts pipeline status next to the work item. It also does not choose or assign reviewers. Nothing here decides who reviews what.

Code review scheduling <em>FAQ</em>

Does Orangescrum automatically assign code reviewers?
No, and it is worth being blunter than that: Orangescrum is not a code review tool at all. There is no reviewer assignment, no diff, no pull request, and no branch approval. Reviews happen in GitHub, GitLab, or Bitbucket. Orangescrum tracks the work around the review, the status, the reserved capacity, and the queue.
Can I see a pull request inside Orangescrum?
No. There is no pull request view. In Self-Hosted, the Jenkins integration shows CI and CD pipeline status against the work item, which tells a reviewer whether the build passed. The review conversation itself stays in your code host.
How do I make the review queue visible?
Add an In review status to your workflow so waiting changes appear as a column on the board and can be counted. Once the queue is countable it becomes a planning problem rather than a complaint.
How much capacity should we reserve for review?
Measure it rather than guess. Ask the team to log time against review for two or three sprints, then plan that average as committed capacity. Most teams are surprised by how much it is.
Which plan or edition do I need for this?
The Kanban board and custom statuses are in all three editions. Sprints are on Cloud Pro and above and included in Self-Hosted. The workload heat map is on Cloud Premium and included in Self-Hosted. The Jenkins integration is Self-Hosted only.
Should review be a separate task or a status?
A status is usually better, because it keeps the review attached to the work it belongs to and stops the board filling with paired items. Create separate tasks only when a review is genuinely large, such as an architectural review.
Does time spent reviewing show up in reports?
Only if it is logged. Reviewers can log time against the task they reviewed, and it then appears in reporting like any other time. If nobody logs it, review stays invisible and keeps being planned as free.

Make the review queue visible

Free 14 day trial, no credit card. Every plan includes unlimited users.

Start free trial

Related

Kanban boardPut the queue where people lookJenkins integrationPipeline status on the work itemSprint and iteration schedulingCommitting to a realistic sprintParallel task executionWhen concurrency is real