SBL

Have you ever been in a training session and found your mind wandering — or even drifting off to sleep? Most of us have. Our brains are wired to learn through doing, not through passive listening.

That’s why Scenario-Based Learning (SBL) is a game changer. It places learners into realistic situations where they must consider options, make decisions, and understand the consequences of those decisions. It transforms theory into lived experience.

Below is an example from one of the Agile Horizons courses.

SBL Example: Understanding Scrum Roles in Real Life

In the course, we first cover the Scrum roles:

• The Scrum Master coaches the team and the organisation, and removes impediments.

• The Product Owner manages the Product Backlog and works with stakeholders on prioritisation.

• The Developers own the Sprint Backlog and are responsible for quality.

This all sounds fine in theory — but what does it actually look like in real life?

This is where a scenario brings the learning to life.

The Scenario

• The team is mid-way through a Sprint.

• A stakeholder contacts a developer they know personally and asks for a “quick, urgent item” to be added this Sprint.

• They insist it’s only 2–3 hours of work.

This scenario works well because:

• It’s familiar to most Agile practitioners

• It contains a sense of tension and urgency

• There is no obvious right or wrong answer

• It encourages debate and critical thinking

Learner Options: What Should the Developer Do?

After discussion, learners typically identify three possible responses:

1. Say Yes

2. Say No

3. Say Maybe – and escalate the discussion

We then consider the consequences of each option.

Consequences

Saying Yes

• The item may not meet Definition of Ready

• It may not get done within the Sprint, risking metrics and commitments

• It sets a dangerous precedent where stakeholders feel they can bypass the process

• The team quietly absorbs the risk

Saying No

• Protects the Sprint, but may damage stakeholder relationships

• Can feel overly rigid or uncollaborative

• May not reflect the spirit of transparency and partnership in Agile

Saying Maybe

• Creates space for proper discussion

• Invites the right roles to be involved

• Balances stakeholder needs with team sustainability

• Is usually the option learners feel most comfortable with

Using the Scrum Roles to Resolve the Scenario

Because the scenario immediately follows learning about Scrum roles, learners now apply the theory to solve a real problem.

A collaboration board works well here — learners add digital sticky notes under columns for:

• Scrum Master

• Product Owner

• Developers

This quickly generates valuable discussion and shared understanding.

Through guided facilitation, learners typically arrive at something like:

Product Owner

• Works with the stakeholder to understand the true priority and urgency

• Clarifies whether this request outweighs other Sprint or Product Backlog items

Scrum Master

• Coaches the stakeholder on how Sprints work

• Explains the importance of Definition of Ready

• Protects the team from bypassing process through personal requests

Developers

• Assess whether the item is feasible

• Discuss implications for quality, workload, and the Sprint Goal

• Collaborate with the Product Owner on possible trade-offs

This approach transforms the learners from passive listeners into active problem-solvers. They are no longer memorising definitions — they are using them.

Benefits of Scenario-Based Learning

This scenario (and others like it) strengthens training by:

• Actively engaging learners in realistic decision-making

• Converting abstract concepts into practical, memorable skills

• Encouraging discussion and peer learning

• Building capabilities such as critical thinking, questioning, and hypothesis testing

• Helping learners see how Agile theory applies to their day-to-day work

Scenario-Based Learning doesn’t just teach Agile — it allows people to experience Agile