8

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?

Improve this question
1
  • 4
    In the context of Scrum, I don't think training tasks should be part of a sprint because training doesn't deliver value to users. Explicitly reducing the team velocity/capacity of a sprint might be more sensible to make the necessary time available. But not all learning has to be scheduled: If devs have to work with an unfamiliar technology this difficulty should be reflected in the estimate – that's not inflating the estimate, it's being realistic. (Comment, not an answer because these are my thoughts, not a authoritatively sourced answer about the Scrum Process).
    – amon
    Commented Aug 18, 2017 at 9:32

3 Answers 3

Reset to default
10

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.

Improve this answer
1
  • I agree. It's not directly related to this project, so don't try to push it in the development process. Processes usually don't get better, if everything is pushed in no matter if it makes sense. And I wouldn't make it a task, because that pollutes your tracker with non project stuff.
    – Simon
    Commented Aug 26, 2017 at 6:25
6

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.

Improve this answer
4

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.