In our organisation, the technical design for the user stories/requirements is done by the onshore resources in the USA and the actual construct/development (coding) is done by an offshore development team.

We follow 1-week sprints.

The question is: how should the story points be assigned? Should they be assigned by the onshore team for the overall story, or just the development effort? Sometimes the actual designing and gathering requirements can take 2 weeks but the development task can be completed within a week.

So the question by the team is: should story points be assigned only for dev effort or overall? Since overall is beyond the 1-week timeline (as in, designing and getting technical requirements done).

PS: I understand that the above may not be pure Scrum. But given the circumstances, how should one estimate? Should there be different story points just for design and development?

  • 1
    What is technical design? How do you do technical design without coding? Consider that code is design, I don't understand what your onshore team is producing for the offshore team to use.
    – Thomas Owens
    Commented Jul 22, 2019 at 19:34
  • Like if its an APi, describe what API we need, endpoints if any vendor systems are involved, authentcation etc. Like the blueprint of solution and the actual construct is done by offshore.
    – Roger
    Commented Jul 22, 2019 at 19:37
  • 4
    I think if you are looking towards lean-agile methods, you aren't going to find what you are looking for. This is inherently not lean or agile. It's very traditional and built on a flawed model of software engineering. We've known since the 1960s that this approach was not how to build software and is filled with risks and problems. I think that the problem of "how to estimate / assign story points" is the last thing that you need to worry about if you want a successful project.
    – Thomas Owens
    Commented Jul 22, 2019 at 19:43

2 Answers 2


The idea of a story point is that is described the approximate size of a piece of functionality. In forecasting, this is usually used to show how much functionality is delivered and how much known functionality remains. With that in mind, it rarely makes sense to apply story points to portions of work.

Additionally, regardless of measurement unit, there are multiple advantages to the people doing the work estimating the work. This presents a challenge to your teams because you have split the work across teams and geographies. However, if you are looking to use story points and relative estimation, you really should have the whole group estimate story points for the whole piece of functionality together.

It is also important that this is not an aggregate (2 points for design, 3 for coding, 2 for testing). It is one number that the whole group agrees on.

  • +1 for your answer. I'd probably mention the need to split/decompose stories too, though. Currently, the OP's teams are taking on "stories" that cross Sprint boundaries.
    – Todd A. Jacobs
    Commented Jul 23, 2019 at 16:16
  • Yeah, I was struggling with the boundaries of the answer. I figured that as nothing else about it is really scrum, I'd confine my answer strictly to the use of "points" in relative estimation.
    – Daniel
    Commented Jul 23, 2019 at 18:06


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:

  1. Work can only be estimated by the task performers. You can't have one team (or person) estimating for another.
  2. 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.
  3. 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.
  4. Each Sprint must have a unifying Sprint Goal, and the work items selected for that Sprint should contribute to that goal.
  5. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.