Why New Team Members Skew Your Estimates (And What to Do)

Adding a developer to a team is always good long-term. In the short term, it disrupts every system the team has built - including estimation.

Why new members estimate differently

New developers don't know the codebase. They're estimating based on what the feature sounds like, not on knowledge of the specific modules, dependencies, and technical debt involved. This produces systematically different estimates - usually lower, because they don't know what they don't know.

The calibration gap

When a senior team member votes 8 because they know a particular area is a nightmare, and a new hire votes 2 because they've never seen the code, the spread is real but the gap isn't a disagreement about complexity - it's a gap in context.

What to do in early sprints

Have new members observe before voting. In the first two weeks, let them participate in discussion and ask questions, but don't include their votes in the consensus. This gives them time to build context without distorting estimates.

Assign them to known stories. In early sprints, give new members stories in familiar parts of the stack (e.g., if they came from a Rails background, start them in the Rails layer). This makes their estimates more reliable faster.

When to bring them fully into voting

After two or three sprints, new team members will have touched enough of the codebase to vote usefully. A calibration session - reviewing a handful of recently completed stories and asking if the estimates still seem right - can accelerate this.

The velocity impact

Expect velocity to dip for 2-3 sprints after adding a developer. Onboarding has a real cost. Plan for it explicitly rather than being surprised by it.

New team members improve teams. In the short term, treat the estimation disruption as a signal to slow down, calibrate, and invest in knowledge transfer.