Count contexts, not estimate sums
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 tax of holding five partial models.
GetToWork rule of thumb (planning assumption, not lab science): treat each new context as roughly 20-40 minutes of setup, and each pull request as roughly 30-45 minutes of fixed overhead across author and reviewer - even when the diff is tiny. Ask estimators "how many contexts?" Then offer the refuse-the-shape script: one hardening change by Thursday, or five separate merges by next Wednesday with review load named.
Setup-cost math (worked example)
GetToWork rule of thumb for planning conversations - not lab science: treat each new context as roughly 20-40 minutes of setup before productive change starts (read ticket, find files, run the right test subset, remember env quirk, open PR scaffolding). Treat each pull request as roughly 30-45 minutes of fixed overhead across author and reviewer (description, review request, pipeline wait, merge conflict check, deploy note) even when the diff is tiny.
Worked example assumptions for one developer day:
| Shape | Contexts | Setup (use 30 min) | Change time | PR overhead (use 35 min) | Rough calendar |
|---|---|---|---|---|---|
| One feature, one area | 1 | 30 min | 4 hours | 35 min | ~5 hours focused |
| Five scatter tickets | 5 | 5 × 30 = 150 min | 5 × 45 min = 225 min | 5 × 35 = 175 min | ~9+ hours before meetings |
The five tickets were sold as "five hours." The rule-of-thumb calendar is closer to a full day plus review load on teammates - and that ignores meeting interrupts. Standup says "worked on five tickets." Merge queue says zero.
Contrast cheap scatter: five copy tweaks on the same marketing site. One CMS session, one preview pass, one publish, one pull request. Context count = 1. Expensive scatter: five copy tweaks across five microservice configs - five loads.
Ask estimators "how many contexts?" Context count drives calendar more than line count. Five one-point stories can exceed one five-point story in a sprint when contexts do not share a working set. Teaching that is unglamorous and saves plans. Background on switching cost: real cost of context switching.
Example: scatter day that looks full
Example tickets: fix typo in admin email template; adjust validation on signup form; bump dependency in legacy cron; 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. The day felt full. Output is thin on both ledgers - motion without integrated finishes (busy vs finishing).
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
- Support duplicates of one root cause (triage into one investigation ticket)
Batch those intentionally (when batching helps): one branch, one review, one verify pass. Product can still track a sub-checklist inside one ticket. Developers get one working set.
If five tickets all serve one user outcome - "checkout trust fixes" - write one ticket and one branch. Splitting for accounting creates artificial switches. Reporting can use checklist items inside an epic without forcing five merges.
When to refuse the scatter (script)
Say no to the shape, not the need. Copyable script:
I can deliver these five as one checkout hardening change by Thursday, or as five separate merges by next Wednesday with review load on Ana and Luis. Which do you want?
That conversation surfaces cost without sounding lazy. Stakeholders choose explicitly: one hardening change vs five merges. If they pick five merges, name the day type: scatter day - low depth, high switch, expect small merges, do not also plan a feature Primary.
Mixing unnamed scatter into a feature day is how planning eight hours into eight hours fails. Feature days refuse scatter except true blockers.
WIP limits and metrics that mislead
Work-in-progress limits force finish before start. They hurt scatter culture that starts five things to look busy. Align limits with a finishing ledger, not a motion ledger.
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.
Support-driven micro-tickets often file many one-line bugs from one root cause. Triage batch: one investigation, one fix, link duplicates as related. Prevents five reloads of the same logs.
Freelance client "quick tweak" lists
Clients send bullet lists of small changes. Estimate the list as a portfolio, not the sum of lines. Offer phased delivery: one deploy with grouped changes reduces their cost too - fewer release windows, fewer regressions.
Example: twelve "small" UI tweaks. Quote as one batch with one staging verify and one revision round, not twelve half-hour line items that ignore setup. If they insist on drip-feed tickets, price the setup multiplier explicitly or move to hourly with a weekly tweak window.
Recovery when scatter already happened
Stop starting. Rank remaining work by dependency and risk. Merge or abandon branches until one or two remain. Communicate slip early with reason "context load," not vague "took longer."
Interruptions amplify scatter: five tickets means five debug surfaces vulnerable to ping (interruptions during debugging). Protect one ticket thread per block when possible.
Batch vs refuse decision tree
Use this when a scatter list lands on your desk:
- Do the five items share one service / one test file / one reviewer? → Batch into one branch and one PR. Checklist inside the ticket for reporting.
- Do they serve one user outcome? → Rewrite as one feature ticket. Subtasks okay; five merges not required.
- Are they support duplicates of one root cause? → One investigation ticket; link the rest as related. Fix once.
- Are they five unrelated areas and still "must be today"? → Refuse the shape with the script above. Offer one hardening change by date A or five merges by date B with review load named.
- Is today already a feature-heavy day? → Park scatter until a named scatter day. Starting five contexts mid-feature is how both ledgers empty.
Example refuse reply that stays professional: "I can take the signup validation and the admin email typo today because they share the web app context. The cron bump and payment logging need a separate scatter half-day or they will blow the checkout Primary. Prefer I batch the web two now and schedule the infra two Thursday?"
Engineering and product can agree: tickets should minimize context count per sprint day, not maximize count for reporting. 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.