Splitting estimates without splitting stories is a known anti-pattern. You should either consolidate the efforts of both teams to collaborate on smaller units of work, or decouple the estimation and delivery for each team.
Splitting Estimates Within a Backlog is an Anti-Pattern
Ideally, your onshore and offshore teams should be collaborating. That would make the effort required for any work a simple aggregate of everyone's contribution, and simplify estimates. There are other models, but this is the agile ideal.
If you truly have separate teams with separate workflows, then you should probably be splitting the work in such a way as to have separate Product Backlogs and a more loosely-coupled set of Sprints. However, if the deliverable both teams are working on is inherently tightly coupled, this is an embodiment of the Scrummerfall anti-pattern. Either the "teams" are a single Scrum team working together on a single Product Backlog, or they are separate teams for which basic Scrum is a poor fit.
There are ways to work with multiple teams, but they generally require a scaled approach that addresses the fact that you don't have a unified Scrum Team working from a unitary Product Backlog. Such frameworks generally require another layer of integration work between the teams (e.g. Nexus), and often involve practices such as test-driven development and continuous delivery to reduce the friction inherent in a multi-team approach.
Work Item Sizes
Regardless of whether you're using a multi-team or single-team approach, you should keep the following in mind:
- Work can only be estimated by the task performers. You can't have one team (or person) estimating for another.
- Work items must fit into a single Sprint. Multi-Sprint work or items that would cross Sprint boundaries should be decomposed using INVEST criteria until each separate user story or backlog item fits entirely within a single Sprint.
- It's okay to have goals, features, epics, or themes that require multiple Sprints to complete, but each individual user story or backlog item must still be small enough to fit into a single Sprint.
- Each Sprint must have a unifying Sprint Goal, and the work items selected for that Sprint should contribute to that goal.
- Each Sprint should deliver a potentially-shippable increment.
In general, agile frameworks optimize for flow rather than utilization. So, when working from one Product Backlog, it's actually more effective for each team to do less work (and thereby create more slack) than to try to have two teams attempting to work at capacity to deliver an increment. The process overhead involved in larger teams or multiple teams means that insufficient slack will actually slow the pace of development, rather than speed it up.
Your objective should be to increase the number of Sprints that achieve the Sprint Goal, rather than to increase the velocity or work-effort for each Sprint. If you focus on the Sprint Goal, the process changes needed to consistently deliver them Sprint after Sprint will become more self-evident over time.