Running an L&D Team with Agile and Scrum

Most L&D teams know the pattern. A six-month program is scoped in detail, designed in isolation, built, piloted and finally launched, only for the business to say it no longer fits. The strategy shifted, the audience changed, or the problem turned out to be something else.

Software teams faced the same problem two decades ago and answered it with Agile. Scrum, the most widely used Agile framework, breaks work into short cycles, puts working output in front of stakeholders early, and builds in regular moments to inspect and adjust.

None of this is specific to code. This post shows how an L&D team can use Scrum's core practices, including sprints, stand-ups, point estimation, sprint reviews and retrospectives, to deliver learning that is faster, more relevant and more visible to the business.

Why Agile fits L&D

Many L&D teams still run projects in a linear sequence: analyze, design, develop, implement, evaluate. ADDIE is a sound framework for thinking, but run as a strict waterfall it delays feedback until the very end, when changes are most expensive.

Agile flips that. Instead of one big launch, the team delivers in small, usable pieces and checks each one with real learners and stakeholders before building the next. The Scrum Guide itself says Scrum is now used well beyond software, wherever teams face complex problems with changing requirements. Learning design fits that description well.

The benefits for an L&D team are practical:

•         Faster value. A first module, a job aid or a pilot session reaches learners in weeks, not months.

•         Less rework. Stakeholders react to real drafts early, so misunderstandings surface while they are cheap to fix.

•         Visible progress. The business sees steady, regular output instead of a long silence followed by a launch.

•         Better focus. A short, fixed cycle limits how much new work can land on the team at once.

•         Continuous improvement. Built-in reflection helps the team get better at how it works, not just what it builds.

If your team already uses iterative design models such as SAM (the Successive Approximation Model), Scrum will feel familiar. It adds the operating rhythm around the design work: how the team plans, coordinates and reports.

The sprint cycle at a glance

Work flows from one ordered backlog into a two-week sprint; the review feeds stakeholder input back into the backlog, and the retrospective improves the next sprint.

Roles and the learning backlog

Scrum defines three accountabilities. Each maps naturally onto an L&D team.

Scrum role	In an L&D team	What they own
Product Owner	L&D lead, program manager or business partner	Ordering the backlog, defining goals, saying no
Scrum Master	A team member or L&D operations lead	Running the events, removing blockers, coaching the process
Developers	Instructional designers, facilitators, content and media developers, LMS admins	Planning and doing the sprint work to an agreed standard

The Product Owner role matters most. It should be one person, not a committee, with the authority to decide the order of work. In L&D this is often the person closest to business stakeholders, who can weigh competing requests against company priorities.

The learning backlog is a single, ordered list of everything the team might work on: new programs, updates to existing content, stakeholder requests, platform improvements and even process fixes from retrospectives. Items at the top are small and well defined. Items further down can stay rough until they get closer.

Write backlog items in terms of the learner and the outcome, not the format. "As a new sales rep, I need to practice handling pricing objections so I can close deals in my first 90 days" leaves room to choose the best solution. "Build a 45-minute e-learning on objection handling" does not.

Agree a Definition of Done too. For learning content it might cover: reviewed by a subject matter expert, accessibility checked, tested in the LMS, and a short evaluation plan in place. Nothing counts as finished until it meets that bar.

Sprints and sprint planning

A sprint is a fixed period, one month or less, in which the team commits to a goal and delivers something usable. Most L&D teams find two weeks works best. It is long enough to finish a meaningful piece of content and short enough to keep feedback flowing.

"Something usable" is the key idea. At the end of each sprint, aim to have output a learner or stakeholder can actually see or try: a finished module, a storyboard ready for review, a pilot workshop, a job aid, a revised assessment. A half-finished course with no usable part does not count.

Sprint planning opens every sprint. The whole team meets for about two hours for a two-week sprint and answers three questions:

1.       Why is this sprint valuable? Agree a single sprint goal, such as "Launch the pilot of the manager onboarding path to one region."

2.       What can we finish? Pull items from the top of the backlog until the team's capacity is reached, based on past sprints.

3.       How will we do it? Break each item into tasks of a day or less, such as script, SME review, build and LMS upload.

Be honest about capacity. Subtract planned leave, scheduled facilitation days and recurring operational work before committing. L&D teams almost always carry some business-as-usual load, and ignoring it is the fastest way to miss every sprint goal.

Point estimation for learning work

Story points estimate the relative size of a piece of work, not the hours it will take. They combine effort, complexity and uncertainty into one number. A 2 is roughly twice the size of a 1. An 8 is big enough that it probably hides risk you haven't found yet.

Points work well in L&D because hour estimates for creative work are notoriously unreliable. Teams are much better at saying "this is about twice as big as that" than predicting exactly how long a script will take.

Most teams use a modified Fibonacci scale (1, 2, 3, 5, 8, 13) and estimate together with planning poker: everyone picks a card privately, all cards are revealed at once, and the highest and lowest explain their thinking. The discussion is often more valuable than the number, because it surfaces assumptions about scope, SME availability or technical constraints.

To get started, pick a well-understood item as your reference. The examples below are only illustrations; your team's scale will be its own.

Example item	Points	Why
Update dates and links in an existing course	1	Small, known, low risk
Create a one-page job aid from approved content	2	Clear scope, one review cycle
Write and record a 5-minute microlearning video	5	Several steps, SME review, media work
Design a half-day virtual workshop	8	New design, facilitator guide, materials
Build a full blended onboarding program	40+	Too big: split it before planning

Anything larger than 13 should be broken into smaller items before it enters a sprint.

After three or four sprints, the team's average completed points per sprint, its velocity, becomes a reliable guide for how much to commit to. Use velocity only for the team's own planning. Never compare it across teams or use it to judge individual performance; that quickly turns estimation into a game.

Daily stand-ups

The daily stand-up (the Daily Scrum) is a 15-minute check-in, held at the same time every working day. Its purpose is to inspect progress toward the sprint goal and adjust the plan for the next day. It is not a status report to a manager.

Many teams use three prompts:

•         What did I finish since yesterday that moves us toward the sprint goal?

•         What will I work on today?

•         What is blocking me?

Other teams walk the task board from right to left, starting with work closest to done. Either works, as long as the focus stays on the goal.

For L&D teams, blockers often sit outside the team: a subject matter expert who hasn't returned a review, a missing brand asset, an LMS access request. The stand-up is where these surface early, so the Scrum Master can chase them the same day instead of discovering the delay at the end of the sprint.

Keep it tight. Detailed design discussions move to a follow-up with only the people who need to be there. If your team facilitates live sessions at different times, an asynchronous stand-up in a shared channel works too.

Sprint reviews with stakeholders

The sprint review is where the team shows what it finished and asks stakeholders what should come next. For a two-week sprint, plan about an hour. The Scrum Guide is clear that it should be a working session, not a slide presentation.

This is the event that changes how the business sees L&D. Instead of waiting months for a launch, stakeholders see real progress every two weeks and help steer it.

A good L&D sprint review includes:

•         A live demo. Click through the module, play the video, walk through the workshop activity. Let stakeholders experience it as a learner would.

•         Early learner data. Pilot feedback, completion numbers or assessment results from anything already released.

•         What changed around us. A reorganization, a new product or a shift in priorities that affects the backlog.

•         A look at what's next. The top of the backlog, so stakeholders can challenge the order while it is still cheap to change.

Invite the people who will actually use or sponsor the learning: business leaders, subject matter experts, and where possible a few learners. Their reactions are the best input the Product Owner gets all sprint.

Retrospectives

The retrospective closes every sprint. The team looks at how it worked, not what it built, and picks the changes that would help most. For a two-week sprint, 45 to 90 minutes is typical.

L&D professionals already believe in reflection for learners. The retrospective applies the same idea to the team itself. A simple format is enough:

•         What went well that we want to keep?

•         What got in the way?

•         What will we try differently next sprint?

Common themes for L&D teams include slow SME reviews, unclear briefs from stakeholders, too many urgent requests mid-sprint, and handoffs between design and development. Each is fixable once it is named.

The rule that makes retrospectives work: leave with one or two specific actions, give each an owner, and add them to the next sprint backlog. Start the next retrospective by checking whether they happened. A retrospective that produces only discussion soon becomes a meeting people skip.

Safety matters too. People need to be able to say what went wrong without blame. Rotating the facilitator and occasionally changing the format keeps the session fresh and honest.

Adapting Scrum to the realities of L&D

L&D work has a few features that software teams don't always face. Plan for them rather than pretending they don't exist.

•         Operational work doesn't stop. Onboarding sessions, compliance cycles and LMS support continue every sprint. Reserve a fixed share of capacity for it, or track it on a separate lane of the board, so it doesn't silently eat the sprint goal.

•         Urgent requests will arrive mid-sprint. Route them to the Product Owner, not individual team members. Most can wait until the next planning session, at most two weeks away. True emergencies replace work of similar size, visibly.

•         SMEs work on their own timelines. Book review slots at sprint planning, not when the draft is ready. Treat SME availability as a dependency when you estimate.

•         Live delivery has fixed dates. A workshop scheduled for a specific day doesn't move with the sprint. Plan backward from it and put the prep work into the right sprints.

•         Not everything ships in two weeks. Large programs still deliver value in slices: release the first module, a pilot cohort or a job aid while the rest is built.

•         Ceremony without purpose. If a stand-up runs 40 minutes or a review is just slides, the events lose their value. Protect the timeboxes and the purpose of each event.

Start with the full set of events as described, then adjust once the team has a few sprints of experience. Changing the framework before you understand it usually removes exactly the parts that would have exposed the real problems.

Getting started

You don't need a transformation program to begin. Try this for your next two or three sprints:

1.       Name a Product Owner and a Scrum Master from within the team.

2.       Gather every open request and project into one ordered backlog.

3.       Agree a short Definition of Done for learning content.

4.       Run a two-week sprint with a single, clear goal.

5.       Hold a 15-minute stand-up every day.

6.       Demo the results to stakeholders at the end, then hold a retrospective.

7.       Estimate in points from the start, but don't trust your velocity until you have three sprints of data.

Agile won't remove the pressure on L&D teams, but it changes how that pressure is handled. Work arrives through one backlog instead of many inboxes. Stakeholders see progress every two weeks. Problems surface in days instead of at launch. And the team gets a regular, protected moment to improve how it works.

That is the real promise of Scrum for L&D: not more process, but a steady rhythm that keeps learning work focused on what the business needs now.

Sources

•         Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide