Split a mixed ticket by behavior, dependencies, and approval requirements. Give each work packet one outcome, a clear owner, explicit non-goals, and evidence that supports an independent review. Set the order before anyone starts changing shared files.
A request to fix billing totals, add an export button, remove an old database column, and tidy the admin page contains several decisions. Assigning the entire request as one implementation task makes it harder to tell which requirement justifies each change. Start by separating what is known from what still needs a product or compatibility decision.
Turn the ticket into distinct tracks
Use a small planning table to expose the different kinds of work. For a mixed billing ticket, the split could look like this:
| Track | First deliverable | Decision needed before implementation |
|---|---|---|
| Dashboard totals | Examples of current and expected totals | Which amounts, filters, and display rules should change? |
| CSV export | A bounded export contract and focused patch | Which selected rows, ordering, fields, and formats belong in the file? |
| Legacy schema removal | Inventory of readers and compatibility requirements | Can old invoices and audit jobs operate without the column? |
| Admin cleanup | Separate cleanup proposal | Which changes are behavior-preserving and worth doing now? |
Assign an accountable person to each track. A billing owner can resolve money semantics; a developer can investigate the existing selection path; a reviewer can own the compatibility gate. Use actual names in the working ticket so dependencies have someone to resolve them.
Make discovery a bounded assignment
Some work should produce information before it produces code. Ask the totals investigation to identify the current calculation, affected fixtures, and the specific disagreement with the requirement. Ask the schema investigation to find application readers, scheduled jobs, and old-invoice assumptions.
Define the investigation's stopping point. A useful result might be a list of consumers with source locations, an unresolved dependency, and a recommendation about sequencing. “Explore billing” has no comparable completion condition.
Keep money-display behavior unchanged until the intended difference is specified. If an audit job still reads the legacy column, record that as a blocker to removal. Its presence gives you a concrete dependency to resolve before designing the schema change.
Choose a first patch that can stand on its own
Prefer a bounded outcome whose dependencies are already understood. An export can be a suitable first patch when it can reuse the table's existing visible-row selection without changing totals or removing schema.
Write the input contract precisely. Does the file contain the current visible page or every filtered row across pages? Which ordering applies? Does the amount use the table's existing currency and display rules? Resolve those questions before implementation; “export the table” leaves important behavior undecided.
For a first packet using the existing visible-row selection, preserve its amounts and ordering. Exclude total recalculation, schema removal, and unrelated formatting. If export requires a new interpretation of billing state, stop and return that dependency to the billing owner.
Give the packet a reviewable acceptance block
Use controlled fixtures and expected outcomes. For example, specify that a paid-row selection contains invoice INV-1 at 1,250 cents and invoice INV-3 at 499 cents. Unpaid invoice INV-2 at 999 cents is outside that selection.
The proposed export checks should require:
- Exactly INV-1 and INV-3, in the agreed order, with USD values 12.50 and 4.99.
- No INV-2 in the exported rows.
- Only the header when the selection is empty.
- No mutation of the source rows.
- Agreement between the actual browser selection and the downloaded file.
These are fixture expectations, not reported results. Check the real application's CSV contract separately: commas and quotes in fields, line breaks, paging, locale, and currency handling may require additional cases. A helper-level check leaves those integration questions open.
Keep the acceptance block tied to behavior. The implementation can vary as long as it preserves the agreed contract and stays within the packet's boundary.
State dependencies and merge order
Describe what each track consumes and what it produces. If export uses the existing selection contract, it may be reviewed before a totals repair. If the selection itself is disputed, resolve that first. A safe sequence follows those dependencies rather than the order of bullets in the original ticket.
Read-only schema investigation can proceed alongside export work when neither depends on the other's unmade decisions. Coordinate edits to shared files explicitly. If two tracks need the same table component, assign ownership or serialize those changes so reviewers can follow each patch.
Schedule admin cleanup separately. Even a useful cleanup can obscure the behavioral change when it modifies the same code. Give it its own scope and compatibility checks.
Match the review gate to the track
For export, inspect the selected rows, amount formatting, empty case, and interface state. Request screenshots that show the relevant table and export control, plus checks that compare the file against the selection.
For dashboard totals, require agreed examples that distinguish the current calculation from the intended one while protecting unchanged money-display behavior. For schema removal, require a migration plan and compatibility proof when schema changes actually enter the patch. The export-only patch can proceed through its own review gate while the schema track remains blocked.
Record which evidence is available and which checks remain pending. Each reviewer should be able to explain why the submitted patch meets its own acceptance criteria.
Define when the ticket returns for redesign
Write stop conditions before delegation. A mismatch between selected and exported rows, an unexplained money-display change, an unresolved audit reader, or a request to edit a protected layer should trigger a pause and a named decision.
End each packet with a handoff: changed files, relevant evidence, unresolved assumptions, accountable owner, and next check. The owner of the final release should also define its stop and recovery conditions. A set of small patches still needs a coordinated decision about what is ready to ship together.
The Agentic Developer Interview includes a task-decomposition card and a completed billing example covering separate work tracks, export acceptance criteria, schema dependencies, review boundaries, and ownership.