Small tickets lie about cost
A backlog of five "one-hour" tickets reads as five hours. Managers stack them into one day. Developers know the truth: each ticket loads a different corner of the system, different tests, different reviewers, different deployment risk.
One medium feature in one area pays setup once. Five small tickets in five areas pay setup five times plus the invisible tax of holding five partial models in head or branch.
Throughput is not the sum of estimates. It is the sum of finished integrations minus reload cost.
Example: scatter day
Example: Fix typo in admin email template. Adjust validation on signup form. Bump dependency in legacy cron job. Add column to report query. Patch logging in payment webhook.
Each item alone is modest. Together they touch templates, forms, batch infra, reporting SQL, and payments. None share a working set. By afternoon you have five branches or one messy branch and five half-tested surfaces.
Standup says "worked on five tickets." Merge queue says zero.
Context switching is the hidden multiplier
Real cost of context switching is not the minute you click another ticket. It is rebuild: read ticket, find files, run right test subset, remember local env quirk, open pull request, respond to bot comments, request right reviewer.
Multiply that by five while meetings interrupt twice and the day is gone without a single user-visible slice.
Review and CI overhead per ticket
Each pull request carries fixed cost: description, review request, pipeline queue, merge conflict check, deploy note. Five tiny pull requests can consume more team attention than one cohesive change with one review narrative.
Teams that reward "closed ticket count" get many closed tickets and slow feature flow.
When small tickets are genuinely cheap
Tickets are cheap when they share context:
- Same service, same test file, same reviewer
- Follow-up from a pull request already open in that area
- Pure copy or config with no logic risk
Batch those intentionally in when batching tasks helps, one branch, one review, one verify pass.
When one feature should swallow the scatter
If five tickets all serve one user outcome - "checkout trust fixes" - write one ticket and one branch. Splitting for accounting creates artificial switches.
Product can still track sub-checklist inside one ticket. Developers get one working set.
Refusing scatter without refusing work
Say no to the shape, not the need: "I can deliver these five as one checkout hardening change by Thursday, or as five separate merges by next Wednesday with review load. Which do you want?"
That conversation surfaces cost without sounding lazy.
Planning days for ticket type
Scatter days need explicit labeling: low depth, high switch, expect merges small. Feature days refuse scatter except blockers.
Mixing unnamed scatter into feature day is how planning eight hours into eight hours fails.
Kanban WIP limits
Work-in-progress limits force finish before start. They hurt scatter culture that starts five things to look busy.
Align limits with busy versus finishing work: finishing ledger, not motion ledger.
Freelance client task lists
Clients send bullet lists of "quick tweaks." Estimate the list as portfolio, not sum of lines. Offer phased delivery: one deploy with grouped changes reduces their cost too - fewer release windows, fewer regressions.
Interruptions amplify scatter
Interruptions expensive during debugging applies per ticket. Five tickets means five debug surfaces vulnerable to ping.
Protect one ticket thread per block when possible.
Metrics that mislead
Story points per ticket, tickets closed per sprint, and leaderboard counts reward scatter. Prefer integrated outcomes: user can complete flow X, error rate down, incident closed with verify.
Recovery when scatter already happened
Stop starting. Rank by dependency and risk. Merge or abandon branches until one or two remain. Communicate slip early with reason "context load," not vague "took longer."
Estimators ask "how many contexts"
Context count drives calendar more than line count. Teaching stakeholders that five one-point stories can exceed one five-point story in one sprint is unglamorous and saves plans.
Example: one branch for five copy tweaks
Example: Five copy tweaks on same marketing site. One CMS session, one preview pass, one publish, one pull request. Cheap scatter because load cost is shared.
Contrast with five copy tweaks across five microservices configs - expensive scatter.
Team agreement on ticket granularity
Engineering and product can agree: tickets should minimize context count per sprint day, not maximize count for reporting. Reporting can use checklist inside epic without splitting branches.
Five small tickets can exceed one feature in real cost because setup, review, and risk do not scale down with ticket size. Batch shared-context work, merge related outcomes, name scatter days honestly, and measure finishes instead of closes. ## Product reporting without forcing scatter
Product can report epic progress with checklist items without forcing engineers to open five branches. Ask for subtasks that roll up to one integration path when possible.
Support-driven micro-tickets
Support sometimes files many one-line tickets from one root cause. Triage batch: one investigation ticket, one fix, link duplicates as related. Prevents five reloads of the same logs. ## Make the habit visible
Put the next review on calendar before you close this week. One recurring block beats remembering when tired. If the habit slips, shrink the review to fifteen minutes rather than skipping entirely - continuity matters more than perfection.
Example: what changed this month
Example: Billable ratio fell because sales calls doubled. Maintenance choice is raise quote for new work and batch sales to two afternoons, not pretend the old ratio still holds. Write that sentence in your rate note so January you is not guessing. ## Make the habit visible
Put the next review on calendar before you close this week. One recurring block beats remembering when tired. If the habit slips, shrink the review to fifteen minutes rather than skipping entirely - continuity matters more than perfection.
Example: what changed this month
Example: Billable ratio fell because sales calls doubled. Maintenance choice is raise quote for new work and batch sales to two afternoons, not pretend the old ratio still holds. Write that sentence in your rate note so January you is not guessing. ## Make the habit visible
Put the next review on calendar before you close this week. One recurring block beats remembering when tired. If the habit slips, shrink the review to fifteen minutes rather than skipping entirely - continuity matters more than perfection.
Example: what changed this month
Example: Billable ratio fell because sales calls doubled. Maintenance choice is raise quote for new work and batch sales to two afternoons, not pretend the old ratio still holds. Write that sentence in your rate note so January you is not guessing.