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 the finished brochures.
Before you promise a delivery date, plan those steps too. 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. They treated acceptance and merging as separate events. A reviewer accepts a change, then merging adds it to the shared code.
They compared Gerrit and Phabricator, two code-review tools. Gerrit’s default workflow starts merging automatically once a change meets the acceptance criteria. With Phabricator, an authorised person has to start the merge.
The researchers measured the share of each review’s total time that passed after acceptance. The median was 1% for Gerrit reviews and 43% for Phabricator reviews. FreeBSD used Phabricator and had the highest project median, 63%. Because the researchers compared different projects over different periods, they could not isolate automation’s effect.
In 56% of FreeBSD reviews, the researchers found no record of human-triggered code-review activity between acceptance and merging. That doesn’t mean people did nothing. The review logs don’t show what they did outside the review system.
Automatic merging has a trade-off. The author loses the chance to reconsider before the system adds the code, and optional feedback can require another round of changes. The study stops at merging. The researchers did not measure when end users received the changes.
Look at your own approval process. Does sign-off start the next step automatically, or does someone have to send a file, instruct a supplier or release a code change? Include that step when you promise a delivery date.
A response isn’t final approval
GitLab’s review policy asks reviewers to respond in under two business days to changes that GitLab team members submit. Assignment to a reviewer starts the clock.
If a reviewer expects to miss that target, they must alert the author as soon as possible, within 36 hours of receiving the request, and try to help find a replacement. If they ask for changes, GitLab tells the author to request review again after making them.
When you ask a client to review a design, agree when their turnaround starts and whether they’re promising comments or a final decision. If they return comments, you’ll need time to amend the design and ask them to check it again. Their response date alone won’t tell you when you can print it.
Follow the brochure through to delivery
The Kanban Guide, by John Coleman and Daniel Vacanti, asks teams to define where a job starts and finishes, how it moves between stages and how they control the number of unfinished jobs. These rules apply throughout that interval, including after approval.
Agree where the brochure starts and what counts as finished. If the finish is delivery of the printed copies, client approval leaves it in progress. Count it among the unfinished jobs while it waits for a print slot. Coleman’s Open Guide to Kanban explicitly includes these queues.
Agree which version the designer will send and how the printer will confirm receipt and acceptance. Check who can book the production slot. Agree what tells the designer that the printer is ready to accept the file, such as a confirmed slot. Client approval alone doesn’t establish that capacity.
Check capacity as well as responsibility. GitLab’s internal tool for choosing reviewers skips people who say they’ve reached their review capacity, as well as those who are away. Reviewers set that status themselves. Someone can be at their desk and still have no room for another review.
Ask the printer about the earliest slot they can offer. You need that information before you can plan delivery. A name beside the task won’t tell you when that person can start.
If the queue keeps growing, discuss how you’ll finish the existing jobs 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. You’ll still need enough people to finish the jobs and carry out the required checks.
Forecast through to delivery
Recent pace can help you forecast a finish when you still have similar tasks to complete. Compare similar completed jobs from their agreed start through to delivery, including time waiting for review and printing. The Kanban Guide pairs a duration with a probability, using past elapsed times where available. GitLab’s response target covers a different interval. Adjust the forecast if the workload grows or the people you need become unavailable.
Record when you submit a design, who takes the review, when they respond and when they approve it. Keep counting while the brochure waits for printing. After delivery, record the whole elapsed time and the reasons for delays. A client considering a design and a printer waiting for you to send the file need different responses.
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 someone has approved but nobody has delivered. Find out who needs to act next and when they can start.