In commercial corporate training and in training for learning and development groups, we have not found the term "requirements" to be commonly used by training groups or HR groups as it is normal for quality engineers, systems engineers and software engineers. More common are training needs and learning objectives. However, in engineering organizations "requirements" are part of the normal lexicon and processes, and in our communications with these groups, we find it easier to use their vocabulary in persuasive endeavors.

A requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform.[1]

ISO 9001 addresses learning customer requirements, meeting them, and measuring how well you met them. Many systems engineering and software engineering projects start with requirements elicitation or generation and a product breakdown structure. Agile software teams tend to use the terms "epics," "user stories" and "tasks" to indicate particular levels of work in the project.

We have found, however, that instructional/LX designers and media staff are more often unaware of the software terms, and these terms may form obstacles when adopting Lean-Agile in training organizations. If you have the need for quickly expanding teams or have people pulled from projects to support other groups, then these terminology obstacles can have even more impact.

In our experience, the more generic and less abstract term, "work items," goes over just as well with training professionals.

Much of the current Agile literature focuses on software product development and describes user stories as the way of expressing requirements, or even collections of user stories forming a larger unit they call epics. The software development community uses this vocabulary for Lean-Agile because it helps scope the work for a completely new product breakdown structure on each project as we continue to reduce batch size for more even flow—a Lean principle.

Consequently, for training teams where we have introduced Lean-Agile, we have called user stories plain old "work items." Work items are more generic and not as software-centric. For training teams supporting software products, it may cause less confusion for the software developers to stick with epics and user stories. But if your shop is not tied to software development, you may find that the language from the software domain is not comfortable for training professionals because of their long exposure to the terminology of training.

You might ask, "Why not just say tasks?" The answer is that a task is just one level of granularity of a work item. We are trying to make the development work in process visible and so need Kanban cards for intermediate work products at all the levels of the courseware product breakdown structure.

As to the courseware product breakdown structure, the training community already has many years using the following product breakdown structure, even if they don’t call it that:

  • Curriculum

  • Courses

  • Modules (sometimes)

  • Lessons

  • Learning Objectives

  • Key learning points or activities

This pattern of specific terms to represent an increasingly smaller scope of work as you go down the list of terms is not new, and it has worked for many years for the purpose of identifying what granularity of scope is meant.

In adapting Lean-Agile to training groups, we followed the pattern of "If it ain’t broke, don’t fix it" and consequently adopted the preceding and historically most commonly used courseware product breakdown structure.

For pure training teams, work items will continue the breakdown with the following:

  • Curriculum (if applicable)

  • Course (if applicable)

  • Module (if applicable)

  • Learning Objectives (LOs)

  • LO Text components

  • LO Media components

  • LO Test Item components

  • Tasks

  • Other requirements (contractual, UI, player functionality, etc.)

If you use an XML-based authoring tool that includes semantic elements for your work breakdown, you can tie these two together by using the same terms that your XML schema uses. Again, it is worth repeating, Lean-Agile asks us to make the development work in process visible, and so we need Kanban cards for intermediate work products at all the levels of the courseware product breakdown structure.

1. Reproduced from Wikipedia article under a Creative Commons Attribution-ShareAlike 3.0 license.

Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview