TL; DR
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?
Spikes
The first step is to reduce your uncertainty as much as possible. Perhaps you need a pair of story spikes, such as:
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.
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.
