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



  • 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.



  • 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?"




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2