I am the scrum master for one of the products in a software development company. Our team, including me, operates from India. However my product owner is in USA. We are working on the feature development for this product that exists for ten years now.

Our team in India started six months ago, with no product nor domain knowledge on it. There are couple of issues that we are facing since then:

  1. Although the team was provided high level knowledge sharing session on domain and the product, the team is not feeling confident enough in converting the user stories to functionality. The main reason I found was that the product was grown so big for the last ten years that the team is unable to figure out various places they have to add/modify the code. Sometimes it took multiple sprints to complete a user story.
  2. The second issue is the by-product of the first issue. As the team is not confident on the changes they have to make quickly, they were unable to estimate the user stories in the sprint planning meetings.

So, is there any guideline that our team needs to follow to create better user stories having in mind that this product is quite old and changed a lot since it was built?

Note that there is another scrum team developing features in parallel in USA for the same product.

  • Hi ramu, welcome to PMSE! I've slightly edited your question trying to make it fit better to our Q&A answer. Could you please review it and amend anything I may have misunderstood?
    – Tiago Cardoso
    Feb 11, 2013 at 12:27
  • Thanks Tiago for reframing the question. Yes, your understanding of my question is correct
    – ramu
    Feb 11, 2013 at 13:45

3 Answers 3



Lack of product or domain knowledge is a process gap, rather than a failure attributable to the team. You can increase the accuracy of your estimates with increased Product Owner participation, training and documentation stories, and story spikes.

All Stories MUST Be Estimated

The team doesn't have the option to "punt" on estimates. At the end of Sprint Planning, all stories accepted into the sprint must have an estimate.

The estimate should be as accurate as you can make it within the time-box allocated for Sprint Planning. This is why the Product Owner must be on hand during Sprint Planning:

  • To answer questions about scope or objectives.
  • To refine or clarify user stories.
  • To remove or replace a story that is truly inestimable with the team's current knowledge.

An estimate is not a guarantee—it's an "educated guess" based on the information available to the team during estimation. When information is lacking, this estimate will generally be wrong; that's simply part of the Scrum process, and the issues that caused a poor estimate should be evaluated—and appropriate mitigations proposed—during the Sprint Retrospective.

Estimates Should Include Uncertainty

[T]he team is unable to figure out various places they have to add/modify the code. Sometimes it took multiple sprints to complete a user story.

A good estimate accounts for the team's level of uncertainty. For example, let's assume a user story about adding a widget to a thingamabob involves changes to an unknown number of classes of uncertain complexity. How should you estimate that?


The first step is to reduce your uncertainty as much as possible. Perhaps you need a pair of story spikes, such as:

  1. Narrow the scope.

    As a developer,
    I would like to know how many classes are involved in rendering a widget
    so that I can estimate the level of effort required to modify it.

  2. Assess the complexity.

    As a developer,
    I would like to measure the complexity of the widget-rendering classes
    so that I can provide a more accurate estimate of the work effort to change them.

If you spend some time on these spikes, your team will be in a better position to offer an informed opinion about the work effort required to complete the original story. In addition, the spikes will provide the team with more confidence that they understand the part of the system they must estimate.

Fudge Factors

Whether or not you do the spikes first, all stories include some amount of uncertainty. However, the bigger the cone of uncertainty, the less accurate your estimates will be. The spikes will reduce the cone, but not eliminate it entirely.

Regardless of the size of the cone, one should always consider the confidence interval when estimating. This will result in story-point adjustments based on the team's current level of knowledge.

  • High Confidence, Small Cone of Uncertainty

    For example, during Sprint Planning the team may be confident that a change is limited to a well-known area of the code, and that uncertainty is therefore small. In such cases, the level of effort may be straightforward to estimate.

  • Low Confidence, Large Cone of Uncertainty

    On the other hand, when uncertainty is high, that should be reflected in the story-point estimate. For example, the team might say:

    The change only involves renaming "foo" to "bar," but we're not sure which classes should be involved in the change. The change itself is probably only 1 point, but figuring out which classes to modify is probably another 5 points. We can't call it a six since there's no such point-card, so let's make this an 8-point story instead.

Remember, story point estimates are a way to communicate resource constraints to the Product Owner and the organization. Right-sizing a story based on uncertainty improves the accuracy of velocity metrics, and more accurately reflects the the speed at which the project can address items in the Product Backlog.

By making the lack of available information about the system a visible cost to the project, you provide the Product Owner the opportunity to prioritize training, documentation, or code refactorings that could reduce drag on the team's productivity.

Create Training Stories

If systems knowledge is lacking, this is a process problem that can't be solved without the cooperation of the Product Owner. Because the Product Owner is responsible for resource allocation on the project through prioritization of the Product Backlog, it is his responsibility to add training and knowledge-transfer stories to the Product Backlog when needed.

For example, if I were the Scrum Master on that team, I would use Backlog Grooming as an opportunity to suggest that the Product Owner add some time-boxed training sessions to the Product Backlog. In addition, I would actively encourage the addition of user stories such as this one to the Product Backlog:

As a maintenance-team developer,
I would like to pair with one of the original developers to document the Foo module
so that I can understand the system better and create more accurate estimates.

Such stories would go a long way towards effectively communicating the underlying process issues to stakeholders. These stories will also directly address a knowledge gap that will continue to plague your project until it is confronted head-on.

  • Thanks CodeGnome for providing some insightful stuff. Idea to creating training stories as part of product backlog is interesting
    – ramu
    Feb 12, 2013 at 6:57

Challenges of working with an offshore dev team

Based on my experience working a similar setup, here are my suggestions:

  • Get one SME from the US to travel to India and train the entire team hands-on for a couple of weeks at a minimum.
  • Get a couple of key team members from India to travel to the US for a few weeks of hands-on training with the SMEs.
  • In addition to the Product Owner, get one SME from the US team to participate in the Sprint Planning meetings. Get the PO to write-up the stories ahead of the Planning meeting. Get the India team to plan out how they are going to implement them as well as estimate and task out the stories. During the Planning meeting, get the US SME to validate whether that is the right approach.

Depending on your budget and motivation, you should try some, if not all of the above. The following, of course, are other must-haves:

  • For better communications, these Planning meetings should be on video, if they are not so already.
  • Your stories should have a clear list of testable acceptance criteria, if that is not the case already.
  • In addition to your other suggestions, pair-programming with the original devs on acceptance tests might be a more targeted solution to the OP's domain-knowledge gap. It's really that communications/information gap that's the core problem, IMHO.
    – Todd A. Jacobs
    Feb 11, 2013 at 18:23

I would look at the complaints in the past years (if some files were kept) and if some clients have asked for reimbursements in the past + what part(s) of the product broke or what the clients were not satisfied with. I would call the customer service and the technical support of your company + those who can repair your product (even if another company does that for you).

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.