Your sprint is full of finished code. Why is nothing ready to release?
The board is full of cards labelled “development complete”. The release is still waiting. Adding more work to the sprint might make the board busier without helping anyone receive a usable change.
A review queue is work waiting for someone to inspect it. It can include code review, testing, accessibility checks or a product decision. AI-assisted coding may increase how much reaches those queues, but the useful question is where work waits in your team.
This guide offers a short queue review for sprint planning. The example is fictional and the numbers are illustrative, not a benchmark or a claim about Georgia’s teams.
Follow the work beyond coding
Pick one recent change and map the steps from starting it to releasing it. Write down the waiting periods as well as the active work. A card can be waiting for a reviewer, actively being reviewed, returned for changes or blocked by missing information. Those are different situations.
Use language that reflects your agreed completion criteria. If review and testing remain, “development complete” should not suggest the change is ready to release. Make the remaining work visible instead of letting a reassuring label hide it.
1. Look at the oldest waiting item
Ask when the item became reviewable, what it is waiting for and what someone needs to act. Do not use the age to rank individual developers. A missing test account or unclear acceptance criterion can leave capable people stuck.
Start with one item rather than a dashboard of averages. An old change may have a specific dependency, while several newer items are moving normally. The age tells you where to investigate, not why the delay happened.
2. Separate queue size from reviewer effort
Fictional board: six small copy changes and two changes to account permissions are awaiting review. Eight cards does not describe the work involved. Note the risk, size and specialist knowledge needed, together with the next available reviewer.
Ask whether the changes could have been made smaller without losing their purpose. A large bundle can be difficult to inspect even if it was quick to generate. Splitting work must preserve working behaviour and meaningful tests, not simply create more tickets.
Choose the next planning move
A fictional team has three changes awaiting the same specialist. That specialist is unavailable tomorrow. The team is about to start two more changes that require the same review. What would you discuss first?
Option A: Start both changes to keep everyone busy
This may increase waiting work. It could still be justified by a dependency or a time-sensitive need, but “everyone is busy” does not explain how the existing queue will move.
Option B: Check how to finish or unblock existing work
This is a stronger starting conversation. Confirm whether another qualified reviewer can help, missing evidence can be prepared or a lower-risk item can move. Do not bypass specialist checks just to make the queue smaller.
3. Make a small agreement for the next sprint
Agree one adjustment, such as protected review time or a limit on starting further changes for a congested review stage. Name who can approve exceptions and how urgent work will be handled. Treat the limit as a team experiment, not a universal formula.
At the next review, examine whether waiting time changed, whether quality suffered and whether work simply moved to another queue. Keep the comparison modest: one sprint can be affected by leave, incidents or a different mix of changes.
Keep the conversation about the system
A useful planning question is: “Which work could reach users if we removed one obstacle this week?” It creates room to discuss review, verification and handover as delivery work.
For people moving into delivery roles, facilitating this conversation is valuable. You can ask for clear evidence and help the team agree a next step without claiming to know every technical answer. The reviewer should still decide whether a change meets the appropriate standard.
You May Also Like
How to make your contribution visible in tech without being the loudest
Sprint planning with realistic capacity: include the work nobody counts
