Published using Google Docs
(FROZEN) 1. IntroductionToScrum_script_jp
Updated automatically every 5 minutes

Introduction to Scrum


Live at

English version originally recorded by MJ (

Translation volunteers: 榎本 明仁, 荒瀬 中人 , Satoshi Kumano


[slide 3: Scrum is usually fake]

The fundamental constraint of knowledge work – such as software development – is our ability to discover and create knowledge.  


But your company is designed for a previous century based on hierarchy and incentives.  


Scrum is optimized for knowledge creation and collaborative invention.


So it contradicts your organization's current policies, habits, and structure.  Those things are hard to change, so most places just rename their current practices to "Scrum."


I made these lessons to help you challenge fake Scrum.


[slide 4: MJ with pointer]

Welcome to Module 1 of Scrum Training Series: Introduction to Scrum.


This is a brief introduction to topics that are covered in greater depth in the other modules.


 I’m Michael James (MJ). I help organizations do Scrum and related Agile practices.


[slide 5: Thumbnail of Scrum Reference Card, clicks through to online document]

This module is subdivided into three chapters.


At the end you’ll find a challenging quiz that’s been shown to increase scores on certification tests and may be a prerequisite to your certification class.  


I also recommend downloading the six-page illustrated Scrum Reference Card.


[slide 6: Scrum Framework]

Scrum is a framework for dealing with complex work such as new product development.


It is an alternative to traditional approaches that were more suited to manufacturing and construction. Why do you need an alternative?


[slide 7: “OLD” assembly line]

[cue scratchy music from the 1940s or 50s]

In the previous century, most people’s work required more of a focus on execution than innovation.


People with defined roles used defined models and defined best practices to execute defined plans that didn’t change very quickly.


[slide 8: “OLD” assembly line is superimposed on the lower left quadrant of the Stacey diagram, in the “Predictable” zone.]

Life was more predictable because we knew more about what


[slide or animation emphasizes “Requirements”]

we were trying to accomplish, and how


[slide or animation emphasizes “Technology”]

we would accomplish it.


People used ideas from Frederick Taylor and H.L Gantt to do predictable or repeatable work.


[slide 9: zoomed out to Stacey diagram]

[scratchy old music stops, or changes to modern music, whatever that is]

Today, a lot of the predictable, repeatable work is done much faster, by machines.


 Things change more quickly.


To stay competitive, we need to inspect and adapt more quickly, and deal with greater uncertainty.


 A transparent framework imposing timeboxes and feedback loops can help us master uncertainty.


[new slide: “Only learning organizations will be able to keep up with the future.”]

Only learning organizations will be able to keep up with the future.


[slide 10: Stacey diagram with framework image in the chaotic zone]

Scrum is a framework for learning about what is needed from the work and how we get the work done


It’s an attempt to put chaos in a box, making the most of uncertainty.


While it’s mostly been used for developing new software products, it may be useful for other kinds of complex work.


[slide 11: blank circuit diagram]

Scrum introduces feedback loops


[existing slide: colored circuit diagram]

encouraging us to inspect and adapt the

[new slide: circuit + product measuring instrument only]

product that we’re building and the


[existing slide: circuit + both instruments]

processes we’re using to build that product.


[slide 12: balanced Agile Movement]

Scrum is associated with the Agile movement described at


We value:

• • • •

individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.






[existing slide: Agile Movement tips left]

This doesn’t mean that we don’t value the things on the right.


[optional animation: balance teeters]

We do value the things on the left more.


[new slide: Running Tested Features diagram] [slide 13]

Early in our product development cycle, we will want to see some features working, rather than one huge release at the end.


Ideally, we’d be able to continue incremental improvements indefinitely.  


Each Sprint we learn more about customer needs and change course a little, or a lot.  


Product development is ongoing, with frequent releases, rather than a one-shot “project.”


[old scratchy music comes back]

[slide 14: waterfall diagram]

Here’s what Scrum is NOT: The attempt to use traditional Gantt ideas for developing software was first described by Dr. Winston Royce in 1970.


He drew a picture, a bit like this one, showing a series of phases.


[slide 15]

[cycle through existing slide sequence showing relay-race baton handoffs]

One phase connects to the next phase connects to the next phase and each one has a hand off.  


In theory, you would do all of your analysis in the beginning, get that completely done,


and then you would start on your design, get that completely done,


and then start on your code, get that all the way done, and then integrate, etc.


That was a nice theory about how things could work, and we suppose it could work if we had perfect knowledge in the beginning, and never made mistakes along the way.


[slide 16]

The next sentence in Dr Winston Royce’s paper (unfortunately, no one read this far), said



[slide: Dr. Royce in the barrel falling down the waterfall]

“I believe in this concept but, the implementation described above is risky and invites failure.”


[slide 17]

[slide sequence: blindfolded team members fail to hand off batons to each other]

The reason it fails for complex work: We rarely have perfect knowledge at the beginning.


In fact, we know less about our project when we are starting out then we’re ever going to know in the future.


Today is the dumbest day of the rest of our project.


But a plan-driven approach requires us to make our most important decisions right at the beginning, when we know the least.  


Waterfall projects eventually descend into anarchy, when the actual work finally happens with low quality and too much overtime.


[slide 18]

[slide: ScrumMaster throws waterfall into blender]

Scrum throws all those phases in the blender. All the ingredients are mixed into every Sprint.


[slide: ScrumMaster with shot glasses] [slide 19]

Instead of dividing the work into activity-specific phases, we divide it into fixed-length iterations, called Sprints.


Every Sprint contains some combination of analysis, design, actual implementation, testing, learning about customer needs, and planning for the future.


 Maybe we’ll actually be deploying or shipping more frequently.


[slide 20]

[optional future animation: shot glasses turn into rainbow circles, then add the loops on top making Scrum swirls]

[existing slide: Scrum swirl + unicycle, bicycle, tandem bicycle]

Starting with the first Sprint, a Scrum team tries to develop a working, tested, potentially-shippable product.  This can start out very small.  We'll call this the increment.


Every Sprint they demonstrate the increment to everyone.  


Customers often need to see the wrong product before they can specify what they really need.  


With short iterations and more feedback we have a better chance of discovering the right product.  


While the Product Owner doesn’t have to actually ship every Sprint, it’s the team’s job to make it possible.


[slide 21]

[existing slide: Scrum swirl, etc. + cross-functional team]

To make a shippable product every two weeks, we’re going to want people with skills in testing, in design, in business requirements, in coding, all on one cross-functional, self-organizing team.


Now, instead of waiting for the end to start our testing, we’ll start testing with our very first Sprint.


Instead of doing all the design up front, we’ll do a bit of design every Sprint, until it becomes continuous design.  


We’ll do small amounts of continuous redesign and refactoring to avoid technical debt.  Every Sprint combines all aspects of the work.


 A Scrum team should collaborate together instead of working in phases with handoffs.


[slide 22]

[existing slide: Roles, Meetings, Artifacts]

Scrum provides a structure of roles, events, rules and artifacts.


Let’s do a quick overview of them now.


[slide 25]

[existing slide: 3 roles]

There are only 3 roles defined by Scrum and we’ll go through each one: Product Owner, Scrum Development Team, and ScrumMaster.


[existing slide: Product Owner] [slide 26]

The Product Owner is the single individual responsible for return on investment (or ROI) of the product development effort.


The Product Owner mostly exerts that influence through the prioritization of the product backlog.


The Product Owner is the final arbiter of requirements questions.


That doesn’t mean that he or she will give you all of the detailed requirements up front, or even all the details at the beginning of each Sprint.


 But the Product Owner does make the final call about those things.


[same slide: Product Owner has a thought bubble with a light bulb in it.]

The Product Owner must have the vision behind the product development.  


Given high uncertainty, it often doesn’t make sense to have a detailed roadmap, but a vision is important.


[new slide: stakeholders funnel concerns through the Product Owner] [slide 27]

 If anyone else wants anything from the team, they need to work through the Product Owner to get what they want.


He or she is the one person making the prioritization decisions. The Product Owner  makes the business decisions, focused more on the what than on the how.


[slide 28]

In Large Scale Scrum, there is only one Product Owner for multiple development teams.


[slide 29: Scrum Development Team]

Now we have the Scrum Development Team.


The Scrum Development Team is a cross functional group responsible for self organizing to develop a shippable product every Sprint.


This is hard to do in the beginning, and today more and more teams are learning how to do it. You don’t want to be the last team that learns how to do this!  


Organizations use the word “team” lightly.  


Think back to a time in your life you were on a real team, where you could all count on each other.  


That’s the kind of Scrum team I want you to create.


If we keep the same team together in the right environment full time, with effective Retrospectives, Sprint after Sprint, they’ll probably get better at working with each other.  

[Alternative sentence that I hope is easier to translate: Teamwork will improve if we establish certain conditions.  Give them the right environment, keep them together full time, and have effective Retrospectives.]


They may become a learning team, the building block of a learning organization.


There are no externally imposed hierarchy or job titles on this team. We leave openings for leadership to emerge naturally, and for control to flow from person to person.


[slide 30]

[new slide: derive from small_vs_large_team_illustration]

The Scrum Development Team is a small group, no more than 9 people. We have millions of years of practice dealing with groups about the size of a family.


Large groups don’t self organize effectively until they divide into smaller teams.  


In Large Scale Scrum, full stack feature teams pull their work from one Product Backlog and integrate their work every Sprint.


[slide 31: Team Room]

Team collaboration emerges most naturally in a team room.  


[slide 32: planet-sized impediment]

If your organization is spread around the world, you’re probably already suffering poor collaboration and coordination; Scrum will quickly bring this problem to the surface.


You may experience breakthroughs by getting your remote people into one room for one or two Sprints in the beginning, and then every few months after that.


Information sharing tools by themselves don’t transform organizations ... and often make things worse.


[slide 33: ScrumMaster]

The Scrum Master is the most misunderstood role in Scrum.


If I’m your Scrum Master, you’re not my Scrum Slave.


It's the opposite. The Scrum Master has no management authority over the team.  


If you are the project manager or line manager of the team, by definition you are not the Scrum Master.


Scrum intentionally leaves out the project manager role.


[slide 34: ScrumMaster + PO + Team]

The responsibilities of project management are split up among the Product Owner and the Team, with the ScrumMaster acting as a kind of facilitator.


[slide: ScrumMaster protects the team from wolves.] [slide 35]

The ScrumMaster protects the team from distractions and interruptions, gets things out of the way of natural team self-organization,


removes impediments affecting the team, facilitates the process, helps teach people how to use Scrum,


promotes improved engineering practices, timeboxes, provides visibility, and somehow does all this without any management power.


It turns out “power” isn’t the most powerful type of influence.


[slide: Scrum Master focus over time.][slide 36]

Eventually the Team and Product Owner don't need as much of the ScrumMaster's attention.


A good Scrum Master does not "make the team do Scrum." Good developers already want to learn and collaborate instead of being directly managed.


A good Scrum Master makes it possible for teams to do Scrum by influencing the organization's policies and structure.  


[slide 37: illustrate the Scrum Master checklist]

For further information on the elusive Scrum Master role, see the “Example ScrumMaster’s Checklist” , an example list of things the ScrumMaster would be concerned with fixing.


[slide 39: artifacts]

Scrum defines three artifacts: The Product Backlog, The Sprint Backlog, and the (Product) Increment.


[slide 40: Product Backlog]

The Product Backlog is a one-dimensional, force ranked list of customer-centric features, prioritized by the Product Owner.


 It’s a list of everything we might ever do. If it’s not in the backlog, it doesn’t exist.


Anyone can add items to the Product Backlog, but the Product Owner has got to prioritize them, and the Scrum Master’s got to make it visible.


A well formed Product Backlog does not contain tasks, only well-formed Product Backlog Items (or PBIs) which might be written in user story form, or maybe use case scenarios.


[slide 41 Force Ranked]

Force ranked means there is only one thing in the top position. Getting organizations to do this is usually a breakthrough.


[slide 42: multiple teams, one Product Backlog]

When multiple teams work on the Product, there's still only one Product Backlog.


[slide 43: Sprint Backlog]

The Sprint Backlog is what we’re planning to do right now to meet our current Sprint Goal.


It has an end date. It has a subset of Product Backlog Items selected for the Sprint, and a plan for how to do them, such as a list of Sprint Tasks.


[slide 44: Multiple Sprint Backlogs]

Multiple teams maintain their own separate Sprint Backlogs even if they work on the same Product.


[slide 45: Meetings]

Now, let’s have an overview of the events in Scrum.


[slide 46: events flowchart]

There are five events defined by Scrum and a sixth one that just about everyone has found useful to do.


The five events defined by Scrum:


The Sprint, Sprint Planning, The Daily Scrum, Sprint Review, and the Sprint Retrospective


The sixth one has no official name so we’ll call it Backlog Refinement.


[slide 47: calendar]

Here’s an example of how those events might fit into a two-week Sprint.  I personally like to end the Sprint on a Friday so we don’t work over the weekend.


[slide 48: Sprint Planning Meeting]

At Sprint Planning, the Team chooses which items to attempt in the sprint.


[slide 49: Sprint Planning Meeting with Sprint Backlog]

The team pulls selected items into the Sprint Backlog, plans how they will do them, and decides whether it’s the right amount of work for them to do. They plan one Sprint.


[new slide: LeSS Sprint Planning Meeting][slide 50]

In Large Scale Scrum, multiple dev teams pull work from the same Product Backlog into multiple Sprint Backlogs.  


They plan to collaborate as a team of teams without intermediate coordinators.


[slide 51: Daily Scrum]

[@VJ: add 15-minute timer]

During Sprint Execution the Team meets once per day for a 15 minute Daily Scrum.


If we’re collaborating we’re meeting all the time of course, but this one official event is defined where we stand up and find ways to help  each other.


We talk to each other. Not to the Scrum Master, not to the Product Owner, not to any kind of boss but to the Team.


I talk to the six other people that are my team members. I look them in the eye and I tell them what I did yesterday (“here’s what I did yesterday”), and I tell them what I’m going to do today, and I tell them what impedes me, what are my blockers. Then I toss the ball to someone else on my team and they talk to the rest of the team.


[new slide: LeSS Sprint Execution][slide 52]

In Large Scale Scrum, each team has it's own Daily Scrum and uses various other collaboration patterns to work with the other teams.


[slide 53]

All coordination responsibility belongs to self organizing teams, so there's no "release train engineer" or other management-assigned coordination role.


The Scrum Master tries to enable self-managing teams, so a good Scrum Master would never do the actual coordination.


[slide 54: SM teaches development skills]

The Scrum Master should help Teams learn continuous integration on the trunk, test-driven development, and other modern development practices.


[slide 55: Sprint Review Meeting]

The purpose of the Sprint Review is to inspect and adapt the Product.  Here, we inspect the results of the sprint and adapt future plans, or the product backlog, to what we learn (during the inspection).


The team demonstrates a potentially shippable product increment to anyone who’s interested — ideally customers and end users.


We get feedback from stakeholders allowing us to inspect and adapt our plans for future development.


A lot of times the feedback is “Hey you did what you said you’d do, but now that we see it we realize that we need something else. And we couldn’t have known that until we saw the wrong product.”


People seem to need a functioning piece of software to react against before they can specify what they really want.


In Large Scale Scrum, there's one Sprint Review of the multi-team integrated product.


[slide 56: Product feedback loop]

Regular Sprint Review Meetings provide feedback about the product and its emerging requirements.


[slide 57: Sprint Retrospective Meeting]

Every Sprint ends with a Sprint Retrospective for the team to inspect and adapt their own process.


We inspect and adapt the way we worked together during the last iteration.


We typically talk about what went well, what could be improved, what we learned and what still puzzles us. We give feedback to each other.


Some practical techniques for doing this well are covered in Module 6. This is really the key of the whole thing: the Team eventually takes ownership of their own process.


[slide 58: feedback loops with instrument measuring “Process”]

Regular Sprint Retrospectives provide a feedback loop about the processes and methods the team uses to develop the product.  


Remember: Scrum is a framework for learning about products and the processes we use to build them.


[slide 59]

In Large Scale Scrum, teams also have their own retrospectives.  


Afterwards, they conduct an overall retrospective with each other, the Product Owner, Scrum Masters, and managers (if there are any).


The Overall Retrospective explores systemic and organizational issues affecting multiple teams.


[slide 60: Backlog Refinement Meeting]

During Backlog Refinement, the Team and the Product Owner get together and they look ahead a little bit into the next few items in the Product Backlog, the items that are candidates for the next couple Sprints.


They clarify them, break the big Product Backlog Items (or epics) into small Product Backlog Items (for example: user stories) so they could imagine doing a few of them in a Sprint, get some input about prioritization, etc.


While this work could also be done in the Sprint Planning Meeting, through experience, people have found it preferable to do it in a separate event on a different day.


Unlike most Scrum trainers, I will measure your understanding of these six modules in the classroom. In other words, I will test you during the class.

You show up already knowing the basics, then we spend most of the classroom time in team activities that go beyond them.

Let me know how you do on the following quiz before coming to class so I can help you with any confusion before it causes any problems in class.

If my version of English isn’t the language you grew up with, remember to slow down on this quiz and during the classroom tests.

If you’re not already signed up and you think you might want to, here’s how to reach me. Most of my public classes are in the U.S. I'm in Asia a couple months of the year, and I’ve helped people in about 20 other countries – anywhere that has good food or, failing that, at least good beer.

[slide 63: VO 59 conclusion]

That was a brief overview of Scrum.


To learn a little more about Scrum, download the Scrum Reference Card and the ScrumMaster’s Checklist.


To learn a lot more about Scrum, attend one of our Scrum classes, or try our other training modules that go into more depth.  


To get coaching in Scrum give us a call.  Also drop us a line to give feedback on this training module.