In short
In general, do not include end-user training in the backlog, but handle it as an off-project duty which makes the team member unavailable whenever trainings are scheduled. This allows the team to know that it doesn't operate at full capacity and act accordingly, without corrupting the backlog or creating unnecessary tensions.
Some more details
What does Scrum say?
Scrum aims to develop a product with a small team. Nothing is said about what's in the product:
- Does training belong to the product to be delivered ? It then belongs to the product backlog and definition of done (e.g. training key users involved in the project).
- Or is the training a separate product to be prepared by another team?
- By the way, is it about training content (course design, training materials, ...) or training delivery (actually telling concrete users how it works)?
Who's responsible?
Accordingly the responsibility depends completely on the project context. But in general:
- Performing training requires different skills, that are not always available in the team. Training does not belong by default to the product IMHO;
- Training often has a different pace of delivery (e.g. new users may arrive and have to be trained, independently of the features being developed), and obeys a different packaging (e.g. feature by feature vs role based training);
- Training can be performed by gifted individuals who are by coincidence also team members. But this does not mean that it's part of the software product development. My short answer assumes you're in that case.
If you're looking for a volunteer, keep in mind that user trainings are best carried out by a trainer. If you have no trainer in the team, and if the customer can't provide a trainer who'd learn from the team, then you should consider the colleagueamigo who has the best understanding of what the user expects and how the feature addresses these expectations. It could be the tester who uses the system and simulate user activitiy. Or ic could be a developer or athe product owner, depending on who uses to to discuss the user-stories with the real users and hence best understands how the features are mapped to the user's expectations.
Why not let the software help to train the user?
When I started software development 40 years ago, my father gave me two advices: 1) The software should be self-explanatory so that the user can learn on the job; 2) Software should be monkey-proof and work without failing whatever the user does wrong, patiently giving instructions whenever necessary.
The two features enable self-learning. And they belong to the product. Meanwhile, industry set the bar higher, with gamification of serious business software to teach the user new knowledge by facilitating self-discovery like in games.