After years of working in teams or alone in product teams or projects, I can't once remember someone defining the time for training. Instead, a feature, task, defect, emergency or regulatory update permanently sidelined everything else.
How often have we been blindsided by someone leaving the team with a month's notice, and their only task for that month is handover notes or training someone else? So let's be entirely fair to those individuals. Handover notes are dull, and you're winding down.
If you take one thing from this post, I want companies and teams to make training a first-class citizen and plan, dedicate resources and budget accordingly.
Why should training tasks be in your backlog?
The simple fact is that tasks that are viewed as "not delivering to the product" fall into the long grass and are rarely given the respect and time needed to add value.
Agile teams spend time breaking down deliverables and give them weight to provide a cadence of delivery. Although the tickets that commonly go into your backlog relate to features or tasks to improve a product, I have been lucky enough to operate in some teams that have given time to technical debt, so why not training tasks?
Training tasks should be in the backlog, so they stay at the forefront of your team's mind, always having an eye on the fact that there may be something new that the rest of the team either does not yet know or understand.
These are what I believe to be just a few of the benefits:
Tasks form part of the team's ceremonies and will go through the necessary story grooming and weighting to identify their value
It highlights to management where time should be spent in ensuring the team is cross-skilling
Training others will become part of your teams sprint or work in progress
Aids in documentation and succession planning
Allows identifying lack of training as costly technical debt
The counter-arguments:
We have communities of practice to share skills across disciplines.
Communities of practice should still run but not be a replacement for team-managed training. Instead, these communities are in place to share discoveries learned, beneficial practices or technologies and are not dedicated to training.
A community of practice is too large to support and train people effectively and should form part of your team culture instead.
We give 10% of our spring or half a day a week for training.
Is it the right amount of time? Have people been able to switch off and focus? Is anything being measured or achieved?
Conclusion:
I can't say that I've seen this done in any team or company. But the more I think about it, the more I see the issues of the lack of management, time and investment given to teams, and the more implementing training tasks into your product backlog makes sense.