Something that bugs me with sprint planning, is where training fits in. Let's say you have a requirement to learn JQuery for a small web application. There would seem to be a number of possible approaches – each with their own potential pitfalls.
Specific task
A task is added to the sprint to learn the technology. The danger is the technology could be complex and so could span a number of sprints turning into a fatlog.
Coupled task
The exact requirements are teased out in advance and are coupled to a bona fide development task.
Inflate task estimate
The development estimate is inflated to include the training. But again, it is perfectly possible the task could overrun.
Assume it will happen in non-productive time
Most sprints allow some slack for non-project work/admin. Just assume that any learning will take place here.
Ignore it
Assume it will just magically happen (dev picks this up in their own time).
Deallocate developer
The developer concerned misses a sprint (in part or in whole) to pick the technology up.
All the scrum documentation I've seen is oddly silent on the matter. Seasoned project managers often seem unsure what to do. As long as the task is done, they don't seem to care how it is achieved.
Is there a canonical way of handling this or is everyone just doing their own thing?
Best Answer
I think you're over-thinking it. Treat it like anything else that isn't directly tied to developing the product (eating lunch, taking a break, attending a presentation, a short work-week due to a holiday, ...)
That is to say, be aware of it during sprint planning and adjust the number of stories you pull in to account for the lost time. If you know the team is going to miss a day or two due to training, pull in about a day or two fewer story points.
The only real goal from a scrum perspective is to be transparent about it. Let the stakeholders know you will be doing fewer points in a sprint, and explain why.
All of that being said, if your team finds it helpful for planning purposes to treat this as a story or as a spike or a task, go ahead and do that.
TL;DR. Don't do anything that you think you're supposed to do, do what actually helps your team move forward.