Besides being “a leader who serves” a Scrum Master is also a coach, facilitator and a teacher. This category is about teaching. Among the Scrum Master’s accountabilities is to make sure that “Scrum is established as defined in the Scrum Guide.” This means that you have to teach Scrum to your team and the organisation. In this section we show you effective teaching methods that will make the information stick.

Learning Pyramid

When you start teaching it is helpful to first learn more about how people learn best. The Learning Pyramid, created by Edgar Dale, shows different teaching methods and the rates of how much information people actually remember.

Passive teaching methods:

• Lecturing 5%
• Reading 10%
• Audio-Visual 20%
• Demonstration 30%

Active teaching methods

• Group Discussion 50%
• Doing, Experiencing 75%
• Teaching others 90%

Some students retain information best through reading and others best through listening. Therefore it is best to vary your teaching methods. For instance, you can follow up a lecture with a demonstration or a group discussion.

6 Trumps

When teaching you want your audience to pay attention and remember what you tell them. One way to help make this happen is using the 6 trumps method from the book “teaching from the back of the room.” It shows you how to setup your session and what you can do to keep people’s attention.

In a nutshell, here are the six brain science principles that make training
stick. When it comes to learning:

1. Movement trumps sitting.
   Stitting still decreases the oxygen levels in your body. That makes thinking and learning more difficult. Make sure that your students move around often. Add some activities to your training sessions where students have to physically move.
2. Talking trumps listening.
   When learners discuss what they have learned, they process the information three times. By listening, by thinking and by restating it in their own words.
3. Images trump words.
   Facts become more memorable when when learners can use mental images to remember them.
4. Writing trumps reading.
   Learners process information a second time when they write it after hearing it. So stop talking and give students time to write a short summary of what they have learned.
5. Shorter trumps longer.
   The brain retains information best when content is fed in smaller chunks of information. In training, divide lecture segments into timeboxed chunks and alternate lecures with other activities.
6. Different trumps same.
   The brain is hardwired to notice changes in the environment and to ignore predictable data. Change your training methods, activities and environment.

Read more detail and explanations in the 6 trumps article.

When explaining the benefits of agile and Scrum it is beneficial to have your agile pitch ready and practiced.

An agile pitch is a short pitch about the benefits of agile way of working. For example:

Agile is a brute focus on value. By learning a lot through constant feedback, we become agile in our way of working to the best possible value for the customer.

Create your own pitch now! And don’t forget: practice your pitch with people you know.

When teaching Scrum to people it is hard to choose the topics you want to talk about without overwhelming the audience with terms like values, pillars, principles and words like Sprint, definition of done etc. etc. But where to start? Let’s say tou have a presentation of one hour to explain the general concepts of agile and Scrum. Here are some talking points you could use.

The key agile values and principles

Should you start with these? They are what everything else is based on. You could explain these in an excercise where people have to match up the left side of the agile values to those on the right. And in doing so explain the values of agile. Explain why do we think there is more value in customer collaboration over contract negotiation. After the exercise post these values on a wall where everyone can see. So that you can point to these in other parts of your presentation. In the interest of time and to avoid overwhelming people you could explain the 12 principles a later time.

Scrum pillars

Next up could be the Scrum Pillars of transparency, inspection and adaption. Explain, talk about them what that actually means and keep them in sight for later reference.

Waterfall (traditional) vs Scrum project

With a few easy graphs you could explain the differences between waterfall and Scrum. Draw a typical waterfall project with the fases after each other. Next, draw a Scrum project with the same phases but then circular. Indicating sprints and iterative working.

Waterfall vs Scrum customer interaction

To explain the differenct in moments of customer interaction in Waterfall and Scrum projects you could draw the following two graphs. The first graph indicates waterfall projects that start with a lot of customer interaction to define the project (red line). And during development and testing there is little customer interaction. Only when the project is released, the customer is back again. The blue line represents the team goind underwater for development.

In Scrum projects the red line of customer interaction is going up and down indicating the sprints. After every sprint the work is checked with the stakeholders to see if we are still on the right track and to “welcome change” to be able to get the maximum value for the customer.

When drawing these pictures you could point out various

Waterfall vs Scrum Value delivery

Working in increments means that a good working product of ‘done’ is ready to be released every sprint. To be released when the PO deems it to be the right time. This means that value is possibly delivered to the customer after the first sprint. Where in waterfall projects the total amount of value is delivered at the end of the project. This is indicated in the two graphs below. The line in Scrum projects could me more of a curve that starts horizontal, goes up and then flattens as the project comes to an end. This indicates that at the start delivery of value might take a few sprints, and in the end slows down as most of the value is already delivered. A customer at this point may decide that enough value is delivered because the state of the product meets market needs.

Scrum framework

Time to dive into the Scrum Framework by drawing a full sprint from sprint planning, through daily stand ups all the way through to the sprint retrospective. And while doing so pointing out the Agile values and Scrum pillars at the appropriate times. (example image) While talking about empiricism, Scrum accountabilities, values etc. You can decide what is appropriate in the time you have.

This will give you a solid foundation to explain the Scrum framework and the differences with traditional project management.

Like Scrum, Extreme Programming is an agile (software) development framework. It aims for higher quality software and a higher quality of life for the development team. Simply said, the major differences are:

• Scrum is a set of management practices to help teams collaborate and deliver value interatively. Scrum consists of no technical or engineering practices. User stories, Estimation, Velocity, CI/CD, TDD etc. are not part of Scrum.
• Extreme Programming is very specific in engineering practices.

Within your Scrum Team it is very much possible to introduce XP practices. Some practices in Scrum originated or overlap with XP. For instance the use of User stories originated in XP. And a Daily Stand Up is required in both frameworks. Have you ever used a Spike to research a tough technical problem? That’s XP!

You can read all about XP’s Rules, Values and process on the Extreme Programming Website. But here are a few useful practices to include in your Scrum Team. The key for a good Scrum Master is to have your teams experiment with different practices and let them discover the value on their own, rather than mandating engineering pracices. You can help your team by asking questions like “Would this bug have happened if we had test-driven developement?”

XP Practices that can benefit your (software) team

Pair programming

Within XP all production software is built by two programmers sitting side by side. This ensures code is reviewed by at least one other programmer and results in higher quality of code and design. In Scrum you could implement this practice for the same reasons. Perhaps not all the time; it is often regarded as inefficient. Even though studies show the opposite.

But it is a great tool to tackle difficult problems in development and to share knowledge among developers.

Spike

A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate. When a technical difficulty threatens to hold up the system’s development put a pair of developers on the problem for a week or two and reduce the potential risk.

Test Driven Development (TDD) and Automated Testing

Test-Driven development is a process of developing and running automated test before actual development of the application. The tests specify and validate what the code will do. It aims to keep the code simple, bug-free and without redundancy. Automated tests are run frequently and whenever a test fails, new code is written and refactored to pass the test and to keep the code simple.

Simple design and Refactoring

Design the simples thing that will work. Start from there. Keep evolving the design of the system. Adding flexibility where it is needed and removing unnecessary complexity. Prevent technical depth by:

• Keeping the design of the system simple.
• Do not repeate code.
• Remove dependencies.
• Make these practices part of the daily development process, do not schedule a “refactoring sprint”.

Teaching User story slicing can be difficult. It takes practice to become better at story slicing. As a Scrum Master you’ll have to teach different methods to the developers and to the Product Owner. Below are different techniques you can teach to your team.

Why slicing stories?

A common problem anong Scrum Teams is that the user stories are too big. Big stories are hard to fully understand, hard to estimate and hard to implement. The risk or work not-done get higher when the stories become bigger. User stories at the top of the backlog should be ready to be included in a sprint. Stories that are lower on the backlog can be large and unclear. They should be refined into smaller stories as it becomes time to concider them in a Sprint planning. But they should not be refined into too small user stories that even a small projects ends up with hundreds of user stories. That would be very time consuming to manage. The size of a user story should make sense.

What is a good size of a user story? A user story should be:

• At least small enough to be completed within a single sprint.
• Preferably small enough that a Scrum Team can deliver about 5 stories per week.
• Small enough to deliver value on it’s own.
• Small, but still make sense.
• Estimable, a good story can be estimated. It’s hard to estimate a story we don’t understand and it is hard to estimate very big stories. (See: INVEST in good stories)

With smaller user stories the stories ‘flow’ though your development process more easily. Also see our section about Flow in our category “Scrum – Not Scrum, but valuable“. And having an increased flow comes with benefits. For instance:

Benefits of smaller stories:

• Every time a story completes, value is added to the system. With big stories it takes more time to add value.
• Developers are more flexible. With big stories developers are always busy and unable to help each other.
• Smaller stories create flow and bottlenecks in the development process become apparent.
• There is more feedback when different stories are completed.
• Keeping track of the progress of the sprint (with burndown charts) is more informative and we can inspect and adapt our schedule more easily.
• Smaller user stories usually contain more detail in the value-part of the story. “So that I can <value>”.
• Smaller user stories might capture early value. See our example under “lookin at language” below.

Techniques of splitting user stories

User story mapping

It can be hard for technical teams to break stories down to smaller stories. But they are often very capable of breaking them down into tasks or a workflow. With user story mapping you add a new dimension to the flat product backlog: context of the customer journey. A user story map is horizontal outlining the steps a user of the ssytem can take. E.g. login – browse products – add to basket – pay. Below each step are user stories or tasks detailing functionality that are needed to complete a step. A horizontal line divides stories by priority. You are now creating a visual map of stories that are in each different release.

You can view an example of a user story map.

Similar to this, you can check out the Hamburger method.

Elephant Carpaccio Exercise

The Elephant Carpaccio exercise is a great way for software teams to practice and learn how to break stories into really thin vertical slices. A side benefit is that it is an excellent opportinuty to explain the benefits of test Driven Development to teams. It is run in a few hours where teams create stories and code a product together in short sprints of about 10 minutes.

Looking at language

Look for conjunctions and comma’s. A story that has a comma or an ‘and’ in the sentence, can often be split into two stories. Look for generic words, verbs, adjectives.

“As an organizer,
I want to send invitations
So that they can come to the events.”

The word “invitations” is generic. Invitations can be sent by letter, e-mail, text-messages, and so on. You could slice the story into smaller ones where the type of invitation is described. This creates more understanding of the underlying technique that needs to be used and if there could be technical difficulties. Thus easier estimating of the story. Sending out a bunch of e-mails is easier than sending out letters. This user story coudl reveal early value. Perhaps the user story of sending out e-mails is valuable right now. But sending out letters is nice to have in at a later time. The PO might decide that letters are not a priority. We discovered early value and are able to deliver value, earlier.

Check acceptance criteria

Split based on acceptance criteria. Acceptance criteria are a list of pass/fail testable conditions that help us determine if the story is implemented as intended. Each user story should have at least a few acceptance criteria. Each acceptance criteria could be examined with the questions: who wants this? and why do they want that? The answer should identify (part of) the value of the user story. It is very well possible that by examining the acceptance criteria you could create a new user story on its own.

Timeline analysis

Imagine the user story is already done. Ask the PO: “What happens when it gets used?” The PO might start to tell a sequence of events with many different actions users are going to take. From this sequence of events we might be able to identify several different user stories that might be smaller versions of the one we have now. In any case, you have even more detailed user stories now.

Data boundaries

Deliver functionality for a subset of data first. E.g. when delivering a sheet with user statistics, for the first sprint deliver a subset of all statistics. This way you get feedback based on a working example early. And it makes it easier to estimate work for the remaining statistics.

Agile aims to improve a process by regular retrospection. Reducing waste is one of the things that can improve your process. Waste is a term that comes from Lean thinking. It describes value and waste as follows:

“Value provides benefit to the customer; anything else is waste.”

If you come across work that provides no value to the customer it is reasonable to ask the question “Should we be doing this?” But sometimes it is not apparent if there is waste in what the team is doing.

Teach your team to identify waste (or impediments) with the Waste Snake

You could teach the Waste Snake. Every time a team member feels as though a task they are responsible for is delayed, they write it down on a post-it note. The note includes the time lost (compared to if they didn’t have the delay), the thing affected, the cause, and their initials. They take the note and add it to the “end of the snake” which is a growing row of notes on the wall. Over time the snake is monitored for repetitive patterns. The issues consuming the most productivity time are prioritized to the top of the list for Scrum Team to focus on reducing or removing.

As a Scrum master you can use this method to get a good insight in what the team thinks of are wasteful and cause delays. You can bring this list to management to see what tasks can be removed from the team. Or perhaps there is a piece of software that causes interruptions for the team? Time to ask management to upgrade or replace this source of waste.

Teams might get so busy that they will try to do everything at once. This often results in many open stories during sprint and a lot of unfinished ones. It is very helpful to teach your team that multi-tasking is really killing productivity.

Loss to context switching

When teams are multitasking, they lose productivity when they have to switch from a task to another task. Jeff Sutherland describes the loss of context switching in his book: “The art of doing twice the work in half the time.” The table shows how much time you lose when you multitask multiple projects.

Number of Simultaneous Projects	Time Available per Project (%)	Loss to Context Switching (%)
1	100	0
2	40	20
3	20	40
4	10	60
5	5	75

WIP (Work In Progress) limits do help in limiting multitasking. See: Not-Scrum (But valuable)

3 Exercises to help teach multitasking is killing productivity

Exercise 1: loss to context switching

You can have your team experience the loss to context switching with this simple exercise:

• Let the people draw three columns.
• The first column is filled with numbers 1 through 10.
• The second column is filled with Roman number I through X.
• The third column is filled with letters A through J.

Round 1:

• Time the round with a stopwatch.
• Start by writing in rows:
  • 1, I, A.
  • 2, II, B. etc.
• When finished write down the time.

Round 2:

• Time the round again.
• Write in colums.
  • 1..10 | I..X | A..J.
• When finished write down the time again.

You’ll notice that the second round is finished faster. This is because there is no loss when the context is switched.

Exercise 2: Myth of Multitasking

This exercise is very similar to the one above. It includes a video and explanation. To summarize when “switchtasking”: time goes up, quality goes down and stress goes up.

Exercise 3: The Name Game by Henrik Kniberg.

The Name Game is a simple game where the ‘worker’ has to write down all the names of the ‘customers’. It is done in multiple rounds, each round less chaotic. It is a great game to show what happens to productivity when someone is constantly interrupted while trying to multitask.

Teams are often so consumed with everyday work that they forget to have fun. As a Scrum Master you must sometimes teach them how to do this. Fun can take many forms. Celebrate success, have a coffee or a lunch walk together, or organize an event.

You can brainstorm with your team if they feel they have enough fun and let them think of ways to add more fun themselves. They might surprise you with their ideas!