Suppose a client approves a brochure. The designer still needs to send the print file to the printer, and someone has to book a production slot. If your plan ends at client sign-off, it gives you no date for either task, let alone delivery of the finished brochures. Before promising that date, establish who takes the next step, because the client can approve the design without taking responsibility for sending it to print.
Waiting to merge the code
Researchers analysed 350,043 completed code reviews in a 2022 study, separating acceptance from merging, which adds an approved change to shared code. They compared two tools: Gerrit’s default workflow starts merging automatically once acceptance criteria are met, while Phabricator requires an authorised person to initiate it.
They measured the proportion of each review’s total time that passed after acceptance. The median was 1% for Gerrit reviews and 43% for Phabricator reviews. FreeBSD, which used Phabricator, had the highest project median at 63%. The different projects and observation periods prevented the researchers from isolating automation’s effect.
In 56% of FreeBSD reviews, they found no recorded human-triggered code-review activity between acceptance and merging. Those logs couldn’t establish what people did outside the review system.
Automatic merging has a trade-off. Authors lose the opportunity to reconsider before incorporation, and optional feedback can require further changes. The study stopped at merging, without measuring when changes reached end users.
For your own approval process, check whether sign-off starts the next step automatically or leaves someone needing to send a file, instruct a supplier or release a code change. That action needs a place in the delivery plan, including whoever has the authority and time to perform it.
A response isn’t final approval
GitLab’s review policy asks reviewers to respond in under two business days to changes submitted by GitLab team members, with the clock starting when a reviewer is assigned. If they expect to miss the target, they’re asked to alert the author as soon as possible, within 36 hours of receiving the request, and help find a replacement. When a reviewer requests changes, GitLab tells the author to request another review after making them.
When asking a client to review a design, agree when their turnaround starts and whether they’re promising comments or a final decision. Comments can leave you needing to amend the design and submit it again, so a response date alone won’t tell you when the brochure can go to print.
Follow the brochure through to delivery
The Kanban Guide, by John Coleman and Daniel Vacanti, asks teams to define where an item starts and finishes, how it moves between stages and how they control the number of unfinished items. Those arrangements continue to apply after approval if the agreed finish is still ahead.
For the brochure, agree whether finished means delivery of the printed copies. If it does, the brochure remains in progress while it waits for a print slot, even though the client has approved the design. Coleman’s Open Guide to Kanban explicitly includes queues when counting unfinished items.
Before handing the brochure over, agree which version the designer will send and how the printer will confirm receipt and acceptance. Establish who can book the production slot and what tells the designer that the printer is ready to accept the file. A confirmed slot could provide that signal, whereas client approval tells you nothing about the printer’s capacity.
GitLab’s internal tool for choosing reviewers skips people who report that they’ve reached their review capacity, as well as those who are away. Reviewers set that status themselves, allowing the tool to distinguish someone who’s present from someone who can take another review.
Apply the same check when speaking to the printer: ask for the earliest available slot before planning delivery. Recording a person beside the task establishes responsibility, but you still need to know when they can start.
If the queue keeps growing, discuss how you’ll finish the existing items before taking on more. Coleman and Vacanti’s guide calls for controlling work in progress. Agree the limit with the team and the customers and stakeholders it affects, taking account of the people needed to complete the tasks and perform the required checks.
Forecast through to delivery
Recent pace can help you estimate remaining tasks when they resemble those already completed. For the brochure’s delivery forecast, compare similar completed projects across the whole agreed interval, including time spent waiting for review and printing.
The Kanban Guide describes a forecast that pairs a duration with a probability, using past elapsed times where available. Make sure those records cover the same start and finish you’re forecasting. GitLab’s review-response target measures a shorter interval, so it can’t tell you how long the brochure will take to reach its recipient. Changes in workload or the availability of the people involved also give you reason to revise the forecast.
Record when you submit the design, who takes the review, when they respond and when they approve it. Continue measuring while the brochure waits for printing, then record the whole elapsed time after delivery, along with the reasons for delays. That detail helps distinguish a client still considering a design from a printer waiting for a file you haven’t sent. Each needs a different response.
Check who can authorise the next step and who can cover for them. If the designer or printer can’t meet the date, raise it with someone who can provide more capacity, change the priority or agree a later delivery.
Choose one design, document or code change that’s been approved but hasn’t been delivered. Find out who needs to act next and when they can start.