1

After we have developed new features in a sprint the users must be trained for using these features. How does this happen in Scrum? Which role should give the training and how should it be reflected in the backlog?

  • Is it a developer (team) task or is it a product owner task or someone else's task?
  • Is it a story in the backlog - it definitely adds value that users know how to use the software - or is it an activity outside of the backlog/sprint?

Thank you for sharing best practices! My most relevant context would be best practices when working as a contractor building and rolling out software for customers. The trained users are employees of the customer.

Martin Bubenheimer
  • 19
  • 3

2 Answers2

4

In Scrum, there are two kinds of backlogs. The Product Backlog is "an emergent, ordered list of what is needed to improve the product" and is maintained by the Product Owner, with input from various stakeholders (including the developers). The Sprint Backlog is "the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)" and is maintained exclusively by the Developers.

I don't consider "training" to be something "needed to improve the product", so it doesn't make sense for it to be in the Product Backlog. You can include the creation or maintenance of training material (such as user guides or example videos on the use of the product) as part of the Definition of Done or as some form of acceptance criteria on individual Product Backlog Items. You could make an argument that training is part of the product and associated services and maintaining the training improves the product, but having it as separate items allows for this work to be ordered independently such that all new development efforts are ordered ahead of training updates, which probably doesn't make much sense.

The Sprint Backlog shows the work that the Developers are planning on doing over the course of the Sprint. If a Developer will be giving a training session or will be writing training content, then it may make sense to put this on the Sprint Backlog. This will help the team consider the impact of this effort during Sprint Planning and keep it visible throughout the Sprint. If the Product Owner will be giving the training, however, that wouldn't need to be on the Sprint Backlog, since the Sprint Backlog doesn't include the Product Owner's work nor does it include ongoing work like refinement, other meetings, and overhead activities.

I would lean more toward training material updates being included in the team's Definition of Done or as acceptance criteria on Product Backlog Items. Exactly how you do this depends on the Scrum Team's involvement. I would also discourage Developers from giving training, since it seems like a poor use of their time and skills, preferring to devote that to either the Product Owner (who is already working closely with stakeholders) or, preferably, to a support organization outside of product development.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • Thank you Thomas for your very clear picture. I like your ideas. It's a good reason to rethink some roles in our organization. I think my concerns came to some extend from too much thinking about how we do it today. – Martin Bubenheimer Mar 07 '21 at 15:37
  • Not sure about discouraging Devs from giving trainings. Scrum Teams are supposed to be cross-functional & cover a range of skills required for product success. I get the point of the PO leading trainings & understand the benefit in scalability/standardisation that support teams can bring, but I'd advise caution not to overdo it. Walling off Devs from target users is at odds with the principle of Genchi Genbutsu. Without tight collaboration, outsourcing training responsibility to a support org is liable to strengthen silos rather than break them. It's reminiscent of Conway's law. – Alex Constantin Apr 28 '21 at 08:57
  • @AlexConstantin Discouraging devs from giving the training isn't the same as walling off devs from users. Devs need contact with users to be effective. In my experience, the devs understand the software, but they don't often have the expertise in training techniques or enough depth in the domain to address things that come up in training sessions. Plus, devs are often much more expensive than support staff who give training, so it could be more cost-effective to hire someone specifically to give training to new users or refresher training to existing users than taking developer time for that. – Thomas Owens Apr 28 '21 at 09:14
  • @ThomasOwens Correct -- I didn't say it was the same thing. Walling off devs would be overdoing it, as would not caring about documentation/training because "it's the support team's job". – Alex Constantin Apr 28 '21 at 09:59
3

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 amigo 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 the 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.

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • Thank you Christophe. To be precise, my question is more about the training delivery. I agree with Thomas that the creation of training material could fit well into the sprint resp. the definition of done. I'm amazed to see that the advices from your father are 40 years old. We are using software that is 20 years old and it does not even come close to meeting these criteria – Martin Bubenheimer Mar 07 '21 at 17:09