How are new team members in a Scrum team most appropriately handled? If they can't directly work on customer driven stories, how are they involved in Scrum's story-centric process? Are they assigned stories?
Depends where you work, really. I don't believe there's anything official in the Scrum documentation for handling this.
What I've seen work well is to just include a lot of pair programming until they get up to snuff. They're definitely assigned stories, though typically smaller ones (be careful of assigning lots of bugs to them, though, as you don't really want a new hire in charge of improving code quality). They're a full member of all Scrum Development Team activities, such as planning and retrospecting.
As in most things, the best way to learn is to dive straight in, whilst having someone to watch over you to make sure you don't drown.
Like many other thing Scrum doesn't (intentionally) tell you how to handle this.
In order to start instilling the right mindset from the start no one on a Scrum team is "assigned" work. The team decides what work it can do, this includes new members of the team. They need to be encouraged to work out how they can best contribute and need to be supported by more experienced members of the team. This may include pairing up with more experienced members of the team, but needs to be a process where they are coached/mentored to participate in the self organsation of the team. They will probably be able to work out what they are capable of doing by collaborating with the other team members.
Onboarding Best Practices in Scrum
Stories Are Never Assigned
Are they [the new team members] assigned stories?
In Scrum, and in most agile methodologies, teams should be self-organizing. That means stories are never externally assigned, and team members should collaboratively divvy up work within an iteration rather than "assign" work.
Product Backlog Items
If they can't directly work on customer driven stories, how are they [the new team members] involved in Scrum's story-centric process?
Onboarding is a process that consumes team resources, and thus should have Product Backlog Items associated with that effort. Some common backlog items include:
- Setting up workstations and toolchains.
- Education about the product development framework.
- Training/coaching on team processes.
- Product orientations, demos, or walkthroughs.
- Anything else related to successful onboarding of the role.
Ideally, the Product Owner prioritizes onboarding stories so that they can be part of Sprint Planning. The Sprint Planning ceremonies should include all effort-driven work planned by the team, not just product features, and successful onboarding certainly requires effort!
Immersive Team-Member Integration
New team members should be involved from the beginning in all team ceremonies, as this is part of the normative process. They should also pair heavily with others on their stories, so as to gain hands-on experience with team processes, codebases, tooling, and so forth. On-the-job training (OJT) is the norm in successful agile implementations.
Productivity Fudge Factors
Note that onboarding will often act as a temporary drag on team capacity for delivering new features, and this is both normal and expected. Adding resources to a project is a long-term strategy, not a short-term fix (see Brooks' Law) and so any short-term reduction in team capacity should balance out over time.
I generally apply a fudge factor of 0.8 to velocity when onboarding stories are included in the Product Backlog, and 0.6 (and some remedial framework coaching) when the Product Owner won't prioritize the necessary stories. Your fudge factors may legitimately vary, but make sure you provide sufficient slack to avoid overcommitting the team during the transition period.
Team members should be voluntarily selecting items (including stories) from the backlog that they can do. In my organization, we have a tech lead on every scrum team who helps junior devs get through issues they might have, explains parts of the code base that are unfamiliar to them, etc. We also sometimes practice paired programming if the team feels it would be helpful. Basically, team members should be picking up stories, they should do so balancing the idea of growing and stretching themselves as developers and also understanding what they really can't do yet, and the entire scrum team should be helping one another work through problems that come up.