The Scrum framework offers an approach to project development and management that is related to the agile software development model. Agile development places an emphasis on iterative development by collaborative teams that are responsive to customer feedback.
Agile methodology does not prescribe specific steps to developing an eLearning or other software product. Scrum offers a team-based approach that fits within the agile paradigm.
The Scrum team
A Scrum team includes a project owner and a scrum master, along with team members. Each team is self-managing. Thus, while the project owner is responsible for communicating the project vision to the team and for representing the customers, including any learners who will use the end product, the project owner is not the manager or boss of other team members. The project owner identifies, prioritizes, and maintains a list of tasks that must be done over the project. This is the “backlog.”
The scrum master is a sort of coach who guides the team in implementing Scrum methods. The scrum master also encourages debate among team members and helps them reach consensus. If the team encounters any barriers to progress, the scrum master attempts to remove or resolve these, facilitating the team’s ability to accomplish its goals during a sprint and throughout the project.
A foundational assumption in Scrum teams is that the development team members are the people best positioned to solve any development problem they encounter. Ideally, a Scrum team has between three and nine members whose expertise includes programming, engineering, project architecture, and more. In an eLearning development project, the team might be a mix of instructional designers, developers, testers, user interface designers, and even animation or audio experts. The entire team takes the project through to completion.
The Scrum framework
Organizations devoted to promoting Scrum emphasize that it is not a process or definitive method; it is a framework for approaching project management and development that allows the development team to choose the best processes and techniques for the problem at hand. Like the agile approach, specific steps are not dictated. Also like agile, the Scrum methodology is iterative; that is, prototypes are tested and user feedback is incorporated into the design during development. This is in contrast to “waterfall” approaches, such as ADDIE, that only provide access to users—and solicit feedback or evaluation—once development is complete.
Scrum development occurs in short bursts called “sprints.” A Scrum team carries out these sprints following the sprint planning meeting.
A sprint can be anywhere from day to a month in length. A sprint creates a defined, usable product, as determined in a sprint planning meeting. During the sprint, the development team may ask the project owner for clarification on the scope and goal of the sprint, but the scope is not changed. Sprints are limited to a month to avoid defining goals that are so complex that changes or scope creep could derail the team’s focus or ability to progress toward the overarching goal.
Likewise, a sprint planning meeting is limited in time. For a one-month sprint, the planning session can be up to eight hours long; planning sessions are shorter for shorter sprints. The planning session defines the goal for the sprint. The scrum master ensures that the team sticks to the time limits. During the planning meeting, the team chooses tasks from the project owner’s backlog to complete during the sprint.
In addition to the planning meeting for the entire sprint, each day includes a “daily scrum.” This 15-minute all-team meeting allows the team members to review the previous day’s work and plan their individual tasks for the next day.
At the end of a sprint, the team holds a sprint review or “retrospective.” At this meeting, the project owner reports on what work items have been completed during the sprint—and what remains to be done. The team conducts a postmortem, discussing what went well, what problems arose, and how they could resolve or avoid those problems in future sprints. The team discussion provides a launching pad for the next sprint planning meeting—and the cycle continues.
Using Scrum in eLearning development
A key element of the Scrum approach is soliciting feedback on each increment and element of the project, throughout the development process. The stakeholders’ feedback is used to improve the design of the eLearning—while it is still under development and changes can be made without scrapping months of development work. “The process allows for software to be developed quickly and changes to be easily incorporated into the process, which improves the quality of the final product, reducing risk and increasing the return on investment,” Karl Kapp writes in “What is a Scrum and How is it Related to ISD?” (see References).
An additional plus of the iterative style and short sprints is that the development process is flexible. It recognizes and accommodates the reality that the project goals or scope might change during development. This might be because the managers requesting the training changed their list of learning objectives, because the tools that learners will need to use have changed, or because additional needs arose. Whatever the reason, a Scrum team can adapt, incorporating new and changed goals into the eLearning under development. In the same vein, if the initial design does not turn out to meet the needs of the stakeholders, or the learners dislike (or misunderstand) the way it works, testing a prototype can reveal where things went wrong—and the problems can be fixed prior to release.
James, Michael. “An Empirical Framework For Learning (Not a Methodology).” ScrumMethodology.com.
Kapp, Karl. “What is a Scrum and How is it Related to ISD?” KarlKapp.com. 16 June 2011.
Scrum.org. “What is Scrum?”
The Scrum Alliance. “Scrum Values.”