How do you make a story point estimate for a story that you are only partially familiar with?

Question

I'm a developer still learning the complexities of a software system on a SCRUM team I joined recently.

I will be asked for a story point estimate for a piece of work that touches areas of the system that I have never worked on before. I am familiar with the technology used to build these areas, however I will need to read up on the design/patterns used, talk to other developers and then run some tests/step through the code, so I can understand how these areas work and how best to make my changes.

The team has a 2 SP baseline story that we use for the relative estimate. Let's say my effort estimate for the new story is 12 points allowing for the added effort I need to exert "learning on the fly". The other developer estimates 5 points as he/she is familiar with the system and does not require the additional learning effort.

In this situation our effort estimates are both correct, for ourselves. So how is this resolved?

I simply don't know with any confidence how much more effort the new story will be, relative to the baseline story. 12 SP is really a guess, just hoping that the story will be no more than 6 times the effort of the baseline.

The options I can see are:

1. My estimate is used as I am the developer assigned to the work (due to limited resources).
2. I do not give an estimate as I do not have any/enough experience and we use the other developers estimate.

On a related note, the iteration manager explained to me that they do not use or measure velocity. I have also heard from another team member that a 13 point story is the most we can fit in one sprint (3 weeks). What value is there in using story points for estimates in this case?

Answer 1

First of all, when estimating a story you should try to keep the learning time out of it as much as possible. If you find yourself increasing your estimate due to unfamiliarity with the area where the story needs to be implemented, then you should consider what your estimate would become if had the opportunity to become familiar with the code before starting with this story.
The reason for keeping unfamiliarity with the code out of your estimate is because

• ultimately, you need to arrive at a team estimate, not the estimate for an individual developer. This means that the estimate should be independent of who ends up working on the story
• stories are often estimated quite some time in advance. Being unfamiliar with the code at the time of estimating does not mean you will still be equally unfamiliar with the code by the time that work on the story actually starts.

---

The process of estimating stories should go like this:

After all developers have given their estimate, then either the estimates are close together or there are some estimates that differ significantly from the rest.
If the estimates are close together, you can just settle on a team estimate that is just the average (or the most given) of the individual estimates.
If there are large differences in the estimates, then at least the developers with the highest and lowest estimates should explain what they considered in making their estimates.
Some common reasons for estimating high are

• seeing complications that the others may have overlooked,
• having a different interpretation of the story
• being uncertain about what is exactly needed
• being uncertain how to realize the story

The most common reason for estimating low is that some part was simply overlooked or that they are overly optimistic.

When discussing the estimates, the goal is to ensure that everyone has the same understanding of the story. In my experience, during these discussions people will start to adjust their estimates and you can get to a consensus for a team estimates.

Answer 2

Your scope is too big. If it is hard or unrealistic to make a good estimate for research and development together, you should have the research part in sprint n and the development part in sprint n+1.

Answer 3

When I do estimates for stories touching a part of our systems unknown to me (I'm the newest member on the team, just over 1 year now) I try to familiarize myself with the code a bit before we go into an estimate. If that is not an option, I simply ask the others how this system or part of a system compares to parts that I already worked on. This way I can get a rough idea how complex it would be to modify it.

Estimates will have a large inaccuracy this way, but if the complexity can not be summarized by the other developers in a couple sentencens, I'd say the estimates have a good amount of inaccuracy anyway.

If the velocity of your sprint is way of, you can get always get back to this story in the Retrospective and think about how to improve the workflow.

Maybe add time for yourself to the next sprint to make yourself familiar with code you haven't touched yet. I do like to write some tests for code I don't know. Or I pick a small story and spend some extra time to read up on the code around it.