How to grasp in a Scrum Sprint the fact that the newest Team member is consuming a significant time from other Team members?

Question

Context

There has been a restructuring where I work and our Team is now led by a guy who used to supervise two Teams. Until very recently he mostly took care of the other Team's activity so, he knows very little about what our Team is doing.

Since he has to lead a single Team, the management told him to spend at least 30% time on development tasks. While the guy is handling legacy projects and L3-support tasks quite well, he requires constant help on getting anything done on our project. My estimation is that the Team spends about half an hour to help or fix his code for each hour he works.

Issue

Our Sprint has a few story points for handling incidents (also for some satellite apps), (optionally) a few story points to handle a non-functional requirement story (e.g. fixing some big tech debt, performance optimization). All the rest goes to handling stories required by the internal client.

The Team is very small, but we managed to have a pretty stable velocity. However, due to Team members spending a significant time helping the Team Leader with his tasks, the Team is not visibly performing better despite being a little bit bigger.

I am wondering about how to formally indicate inside the sprint that Team members can commit less because they need to help the newest member.

One way would be to increase the story points for the stories assigned to the newest member so that the effort reflects the reality (extra time spent on solving it) and take a little less for the other stories. However, this might make the PO wonder why the same Team members can commit less individual work.

If the newest member had been a Junior (as opposed to being a Senior Dev promoted to Team Lead), it would have been easy, because any sane person understands that junior members require help and mentoring.

Answer 1

When you onboard a new team member there are two things you need to do:

• Reflect the change in your capacity to do work
• Inform your stakeholders of the impact of the onboarding

It is up to you how you do these things. For example, some teams might add 'onboarding tasks' to their backlog that cover the time needed to get the new team member up to speed. Another approach would be to simply allow your team's velocity to adapt to the change (it will likely drop at first, then recover).

A good way to inform your stakeholders is to mention the onboarding and the impact it is having at the sprint review meetings.

The important thing is to be transparent about the change and the impact it is having. The onboarding of any new team member will initially reduce the team's capacity to deliver work. This is true even if you are onboarding a senior and experienced developer.

One way would be to increase the story points for the stories assigned to the newest member so that the effort reflects the reality (extra time spent on solving it) and take a little less for the other stories.

I wouldn't advise this approach. Story points are a measure of the relative difficulty of the team doing a task, not an individual.

Having said that, the new team member should also now be contributing to estimates. For example, you might have a conversation like this when estimating:

Existing team member: "This story feels like about 3 points"

New team member: "I don't have much experience doing this kind of work and would likely struggle with this story. It might be an 8 point story for me."

Existing team member: "OK, shall we reflect that by making this a 5 point story, to take in to account the capability of everyone in the team to do this work?"

Answer 2

Any new joiner to the team will require time to learn the works of the project and will require time spent from others in the team to help them and offer support. Nobody hits the ground running, no matter if they are a senior, a junior, or someone who managed teams.

Many think that adding a new team member immediately adds positive results to the team and the progression from that point on for the individual will look something like this:

The reality though, is that productivity takes a dip with any new joiner and things will plateau at some point, with a realistic plot looking like this:

If you want to make this visible:

• You could put an "onboarding spike" in the sprint to make it visible that there is work going on to help someone get up to speed. You can estimate it in story points if that's what you usually do with spikes, although often they are just time-boxed.
• Or, when you plan your sprint, you could decrease the capacity of the team to reflect that some members have reduced capacity this time and not all of it can go to develop actual features. It's just like someone being on vacation for a few days or so. Capacity is tied to velocity so velocity will decrease, but that's what happens when the team structure changes.
• Or you just take fewer features in the sprint to accommodate for the needed time to help someone new.

It doesn't really matter as long as people understand why there is a change in the team and how that reflects on delivery in some way or another. If people believe that things will improve instantly if you add a new warm body to a team, then that's delusional and subject to another question/answer.

Answer 3

It depends. If the organisation in question is generally used to people flowing in and out of teams, and if everybody is up to speed technically, and infinitely adaptable in psychological terms, then the effective resource capacity and the number of people is nearly the same number, at all times. Lucky you if that happens.

However, if team building is rare, or even just occasional, and you are dealing with normal humans, then you can expect at least one of these effects:

• Learning curve as the new person gets used to the technical aspect of the job. Refer to Bogdan's curve for example. As they get used to what's where and what things are called, they ask fewer questions, and everyone else can get on with stuff.
• Movement of the team stage back to the Storming stage (refer to Tuckman's well known model).
• Adjustment of working culture : the less technical aspects of team roles (e.g. Belbin Types) may shift as the new person makes an impact.

You can't be prescriptive about how long this might take. It might be a couple of weeks, or perhaps years.