--- title: "Code Review Scheduling: A Practical Guide | Orangescrum" description: "How to schedule code review as planned work instead of a favour: response times, reserved capacity, and a visible queue." canonical: https://www.orangescrum.com/optimization/code-review-scheduling --- # Code Review Scheduling: A Practical Guide | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Planning techniques](/optimization) / Code review scheduling 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](/sign-up?utm_source=site&utm_medium=technique&utm_campaign=optimization_code-review-scheduling) [See all features](/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 done**A 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 everything**The 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 plan**The 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-up**Reviews 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 column**A dedicated In review state puts waiting work on the same board as everything else, so the queue gets discussed instead of assumed away._Kanban board_](/kanban-board)[**Define what in review really means**Set 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 statuses_](/custom-status-workflow)[**Reserve capacity for reviewing**Plan 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._Sprints_](/agile-project-management)[**See who is carrying the queue**A workload view shows the person who is both delivering their own work and reviewing for everyone else. That person is usually the bottleneck._Workload management_](/workload-management-software)[**Show build status on the work item**In 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 integration_](/integrations/jenkins)[**Track what review keeps finding**Log recurring issues raised in review as defects linked to the work, so a pattern becomes visible instead of being rediscovered every time._Defect tracking_](/bug-and-issue-tracking) ## How to _schedule review properly_ 1. **Decide who can review what**Write 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 loud**Something 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 board**Add 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 sprint**Estimate 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 work**At 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 FAQ 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](/sign-up?utm_source=site&utm_medium=technique_cta&utm_campaign=optimization_code-review-scheduling) ## Related [**Kanban board**Put the queue where people look](/kanban-board)[**Jenkins integration**Pipeline status on the work item](/integrations/jenkins)[**Sprint and iteration scheduling**Committing to a realistic sprint](/optimization/sprint-iteration-scheduling)[**Parallel task execution**When concurrency is real](/optimization/parallel-task-execution)