How should training activities be handled in Agile/Scrum

Within the context of Scrum, I see a few different possibilities:

1. The training is in the form of an official course with required/expected attendance at specific dates. In this case, I would treat those course dates as planned vacation days as far as the sprint planning goes. This means that the person(s) attending the course are not available some part of the sprint and the expected velocity has to be adjusted for that.

2. The training is directly related to one or more stories on the backlog, but is not otherwise tied to specific dates. In this case, you can create a spike (a technical story with a fixed duration/timebox, usually used to investigate stuff) for doing the training. If it is a longer study with clearly identifiable modules, then you could also create a separate spike for each module.

3. The training is not project-related and not tied to specific dates. This would typically be a "personal development" type of training. As it doesn't add value to the project (also not indirectly), but does take someone's time, the fairest solution here seems to be to take the training into account in the availability or focus factor of the one taking the training. This does not have to mean they are completely de-allocated.

Although it's not something that is described in the Scrum Guide, the concept of a Spike is pretty well known (Wikipedia, Mountain Goat Software, SAFe).

A Spike is a specific task.

Planning the Spike. Although some people say to not put them on the Product Backlog, I find it helpful for planning purposes, especially if you identify the need while performing a Backlog Refinement for items that are not slated to happen for a sprint or two - you may decide to defer the spike until the sprint before it's needed. Of course, this does break the Scrum Guide's definition of what a Product Backlog is, but I think it's important to do what works for the team.

Estimating the Spike. You don't typically estimate spikes. You timebox a Spike. They could cross Sprint boundaries, even. Instead of estimating them, you define an objective or a scope and complete it by a given date. However, something that may work is putting an upper bound of effort on the Spike in your units of estimation (hours, points, whatever). For example, if you use Story Points, you can put Story Points on the Sprint. Whoever is working on that Spike spends that level of effort on the Spike. If it ends up being more complex, you can go into a replanning to decide how to reorder the Sprint and Product Backlogs based on this extra work. Personally, I find not estimating them and completing them within the bounds of a Sprint (to enable work on another Product Backlog Item in the next Sprint) or before the next Backlog Refinement session (to allow for estimating the Product Backlog Item) to be the most useful.

Scheduling the Spike. If you follow traditional guidance and don't estimate a Spike, you do need to consider the impact to velocity if one or more members of the development team are working on an item. Because it's work with no estimated points or time but still has to be done (using effort and time), it will prevent you from doing other work.

Spikes are only useful for training specifically tied to the product and project at hand. For example, some training - compliance or regulatory training and professional development - isn't necessarily tied to work done on a specific project.

These types of training should be factored into capacity. If people have training that is estimated to take a day, you should reduce your velocity appropriately (assume an extra non-working day for the team members who are doing the training).

These types of things should not be on the Product Backlog or in a Sprint Backlog at all, and the project team shouldn't estimate them. They exist outside the project management methodology but impact how the work is done.