To get accurate story points from an offshore team, the people who will build the work have to estimate it, at a time that's inside their working day, in a format that makes it safe to disagree with the onshore lead. Time zones are the easy part. The bigger problem in distributed agile estimation is usually that offshore engineers are in the session but don't feel able to vote what they actually think.
This guide covers both parts: the logistics, and the language, culture, and hierarchy dynamics that quietly skew estimates.
The usual failure pattern
Here's a common setup. The product owner, Scrum Master, and two senior engineers are in Chicago. Six engineers are in Pune, working through a vendor. Planning poker happens at 9am Chicago time, which is 7:30pm in Pune. The Pune engineers join with cameras off. When cards are revealed, the Chicago tech lead's 3 sits next to five 3s from Pune. "Great, consensus." Two days into the sprint, a Pune engineer flags that the story touches a legacy reporting module only their team maintains, and it's really an 8.
Nobody lied. What happened was a mix of:
- Bad timing. The meeting was at the end of the Pune team's day.
- Anchoring. Someone said "this is pretty simple" before the vote, and it was the most senior voice in the room.
- Hierarchy. Contradicting the client-side lead in front of the client felt risky.
- Language load. Explaining a technical objection quickly, live, in a second language, is harder than agreeing.
- Missing context. The story was written for the people who wrote it.
Each of these has a specific fix.
Fix the timing first
If offshore engineers vote at 8pm their time, you get tired estimates from the people with the most implementation knowledge. Your options, from best to worst:
- Async-first estimation. Stories are posted with full context, people vote blind on their own schedule within a 24 to 48 hour window, and only the spreads get discussed live. Our async estimation guide has a full 48-hour cadence, an overlap-window table, and reminder templates.
- A short sync call in the real overlap. For India and the US East Coast during US summer time, 8:00am New York is 5:30pm in India. That's the edge of the day but workable for 30 minutes. Keep the live portion to outliers only.
- Rotate the bad slot. If someone has to be up late, make it alternate. The onshore lead joining at 7am sometimes says more about respect than any slide deck.
- Regional pre-estimation. For large programs, each site estimates in its own hours and a representative from each meets to reconcile differences. This scales, but it drifts unless both sites share the same reference stories (see below).
What doesn't work is "the onshore team estimates and offshore implements." You lose the implementation knowledge, and the offshore team learns that their opinion isn't wanted.
Language: make it easy to disagree in writing
Many offshore engineers work in English as a second or third language. They're often fully fluent in reading technical English and less comfortable arguing quickly in it, live, against native speakers. Planning poker discussion rewards fast talkers. Some ways to level that:
- Collect a one-line reason with every vote, in writing, before the discussion. "8: touches legacy reporting module, no tests." Written reasons let people prepare their words, and the facilitator can read them aloud so the person doesn't have to argue alone.
- Post stories 24 hours ahead. Reading time helps everyone, and it helps second-language readers most.
- Plain story language. Avoid idioms ("low-hanging fruit," "boil the ocean"), sports metaphors, and abbreviations only the onshore office uses. Write "out of scope: mobile layout" instead of "mobile is a stretch."
- Slow the facilitator down. Pause after asking a question. Count to five silently. Silence on a call isn't a no.
- Allow chat answers. "Type your reasoning in chat if that's easier" opens the door for people who process better in text.
- Summarize decisions in writing at the end of each story, so nobody leaves with a different understanding of what was agreed.
None of this is about lowering expectations. It's about not letting fast spoken English decide the estimate.
Hierarchy and culture: the deference problem
Cultures vary a lot in how comfortable people are openly contradicting someone more senior, or someone on the client side of a vendor relationship. Geert Hofstede's "power distance" dimension is a common way to frame this. Treat it as a hypothesis about your team, not a stereotype about a country. Individuals vary, and plenty of offshore engineers will push back hard once it's clearly safe to.
In a vendor relationship, the structural pressure is real whatever the culture: the onshore lead is effectively the customer. Saying "your estimate is wrong" to a customer is a career risk in a way it isn't for a peer.
What helps:
| Problem | Fix |
|---|---|
| Seniors talk before the vote and anchor everyone | Rule: no numbers, adjectives ("simple," "huge"), or comparisons before reveal. The facilitator stops it every time. |
| Offshore votes cluster around the lead's vote | Hidden votes, simultaneous reveal. Seniors commit to their own card before saying anything about the story. |
| High voters stay quiet after reveal | The facilitator asks the high voter first, by name, with a curious question: "Ravi, what's in your 8 that we might be missing?" |
| "Yes" means "I heard you," not "I agree" | Ask open questions ("What could make this take longer?") instead of yes/no ("Does that make sense?") |
| Vendor team fears looking slow | Leadership says it out loud: "High estimates that turn out right are what we want. Low estimates that blow up mid-sprint are the problem." |
| Offshore team never facilitates | Rotate the facilitator role across sites |
A facilitation script for the reveal
Use this exact wording until it becomes habit:
"Before anyone explains, I'll read the spread: 3, 3, 5, 8, 8. We're not looking for who's right. The 8s probably know something the 3s don't, or the reverse. Meera, you voted 8. What are you seeing? ... Thanks. Tom, you voted 3. What are you assuming we don't have to do? ... OK, does anyone want to change anything before we re-vote? Re-voting now."
Thank the high voter specifically, especially the first few times. People notice what gets rewarded.
Watch for the quiet signals
- Identical votes from a whole site, every time. That's often coordination before the call, or deference. Not necessarily bad, but ask.
- "?" never gets used. Make it explicitly acceptable: "A '?' tells us the story isn't ready. That's useful."
- Estimates change after a senior speaks, but reasoning doesn't. If someone moves from 8 to 3 without saying why, ask gently: "What changed for you?"
Shared reference stories across sites
Point values drift between sites. Pune's 5 becomes Chicago's 3 because each site is calibrating against different past work. Prevent this with one shared reference set:
- Pick two or three completed stories each for 1, 2, 3, 5, 8, and 13 that both sites worked on or reviewed.
- Write a sentence for each about why it was that size: "5: new API endpoint, existing auth, one DB migration, needs contract test."
- Show the reference list at the top of every estimation session or async batch.
- Recalibrate quarterly by comparing a few recent stories against the references. Our story point calibration guide walks through a calibration session.
Write stories that travel
Stories written for the person sitting next to the PO lose context the further they travel. For distributed estimation, every story needs:
- Business context: why it matters and who uses it, in two sentences.
- Acceptance criteria with one concrete example.
- Out of scope: what it deliberately leaves out.
- Known unknowns written down, not assumed.
- Which system or module it touches. Offshore teams often own specific modules and will spot the risk immediately.
- A reference story for comparison.
If an offshore engineer has to ask three clarifying questions before voting, the story wasn't ready. Track how often that happens and fix it upstream.
A worked example: a two-site sprint
A hypothetical team: PO and two engineers in Chicago (CDT, UTC-5), five engineers in Pune (IST, UTC+5:30). That's a 10.5-hour difference.
| Day | Chicago (local) | Pune (local) | Activity |
|---|---|---|---|
| Mon | 9:00am | 7:30pm | PO posts 10 stories with references. Pune reads Tuesday morning. |
| Tue | 10:00am to 6:00pm | Pune posts questions in story threads. | |
| Tue | 8:00am to 12:00pm | PO answers. Pune sees answers Wednesday morning. | |
| Wed | 10:00am to 4:00pm | Everyone votes blind in a form with a one-line reason. Chicago votes on Tuesday afternoon. | |
| Thu | 7:30am | 6:00pm | 30-minute live call: only the 3 stories with spreads larger than one card. Pune engineers' written reasons are read first. |
Result: seven stories were settled without a meeting, three were discussed with the implementers present, and nobody joined a call after 6pm their time.
Where tools fit
Any planning poker tool with hidden votes and simultaneous reveal works for the live outlier call. If you use Alignlee, it's free, needs no accounts (people enter a name and join with a link or 6-character code), and works in mobile browsers, which helps when a site has locked-down laptops. Votes are shown with names on reveal, so pair it with the "ask the high voter first" habit. Rooms last 24 hours, and votes reveal automatically once half of the voters in the room have voted, so for multi-day async voting a hidden-response form is the better tool. See remote planning poker for running the live part.
Common mistakes
| Mistake | Fix |
|---|---|
| Onshore estimates, offshore implements | Implementers always vote, even if it means async |
| Live sessions at 8pm offshore time, every sprint | Async-first, short overlap call, rotate the bad slot |
| "Any questions?" followed by moving on | Open questions, pause five seconds, invite chat answers |
| Senior says "easy one" before voting | No numbers or adjectives before reveal |
| Treating unanimous votes from one site as consensus | Ask one person from that site to explain the reasoning |
| Separate reference stories per site | One shared, written reference set |
| Blaming the offshore team for "slow" velocity | Compare estimates to actuals together; fix the process, not the people |
For the wider picture of management pressure on estimates, see management pressure and estimates.
FAQ
How do you do story pointing with an offshore team?
Post stories at least a day ahead with business context and reference stories, collect hidden votes with a one-line written reason inside the offshore team's working hours, then hold a short live call only for stories with a wide spread. The people who'll build the work must vote. Ask the high voter to explain first so disagreement is invited, not just tolerated.
What is distributed agile estimation?
Distributed agile estimation is relative estimation (story points or T-shirt sizes) done by a team spread across locations and time zones. It usually combines async blind voting with a brief synchronous discussion of outliers, plus a shared set of reference stories so a 5 means the same thing at every site.
Why do offshore teams always agree with the onshore estimate?
Usually because of anchoring and hierarchy, not real agreement. If a senior or client-side person signals a number before the vote, or if contradicting them feels risky in a vendor relationship, estimates converge on theirs. Hidden votes, no numbers before reveal, written reasons, and asking the high voter first all reduce this.
Should offshore team estimation happen separately from the onshore team?
Only for large programs, and only with shared reference stories and a reconciliation step. For a single Scrum team, estimate together, async or in a short overlap call, because the discussion of differences is where the hidden complexity comes out.
How do language barriers affect planning poker?
Live debate rewards whoever speaks the shared language fastest, which can bury the best technical objection. Written vote reasons, stories posted a day ahead, plain language without idioms, pauses after questions, and chat-based answers all help second-language speakers contribute fully.