Start with 7 free days of training.

Gain instant access to our entire IT training library, free for your first week.
Train anytime on your desktop, tablet, or mobile devices.

Preparation for Scrum Master, Product Owner, and Scrum Team Certification

This course will be retired in 584 days. If you have questions, please contact us.

This course provides a comprehensive review of the Scrum development approaches and the knowledge and skills needed to become a Certified Scrum Master. This course will prepare you to take the Scrum.org Scrum certification exam and also can be used to help prepare you for the classroom training component of the Scrum Alliance certification exam....
This course provides a comprehensive review of the Scrum development approaches and the knowledge and skills needed to become a Certified Scrum Master. This course will prepare you to take the Scrum.org Scrum certification exam and also can be used to help prepare you for the classroom training component of the Scrum Alliance certification exam.

Trainer Steve Caseley provides an overview of Scrum, including the roles, activities and project management tools. Steve breaks down the specific duties of each Scrum Role: Scrum Master, Product Owner and Scrum Team, as well as the Scrum rituals that form the core of Scrum. The course also explores the similarities and differences between Scrum and traditional development approaches and examines the six different Scrum certifications from the Scrum Alliance.

This training has been approved for Category A PDUs. For a listing of how many PDUs are earned for this training, please visit our PMI R.E.P. FAQs on our Forum.

Related area of expertise:
  • IT project management

 show less
1. Introduction to Scrum (35 min)
2. Scrum versus Traditional Development (32 min)
3. Scrum Roles (38 min)
4. Scrum Meetings (38 min)
5. Scrum Artifacts (38 min)
6. Scrum Master (32 min)
7. Product Vision and Product Backlog (41 min)
8. What is done? (27 min)
9. Release and Sprint Planning (34 min)
10. Scrum Estimating (34 min)
11. A Sprint (39 min)
12. Daily Scrum (25 min)
13. Tracking Progress (33 min)
14. Dealing with Changes (25 min)
15. The Product Owner (31 min)
16. Sprint Review and Retrospective (31 min)
17. Backlog Grooming (34 min)
18. Writing User Stories (34 min)
19. Team and Business Dynamics (43 min)
20. Technology and Process Debt (35 min)
21. Agile Development Techniques - 1 (30 min)
22. Agile Development Techniques - 2 (28 min)
23. Delivering Large Projects with Scrum (36 min)
24. Distributed Scrum (35 min)
25. Scrum Process Improvement (24 min)
26. How to Deal with Organizational Resistance (41 min)
27. How to Get Started with Scrum (31 min)

Introduction to Scrum


Welcome to this series on scrum master preparation. Scrum is a very widely recognized agile development process. This nugget is going to introduce you not only to scrum but introduce you to the specifics of scrum master certification or the process to follow to become a scrum master.


In this introductory series we're gonna cover the very high level of what scrum and scrum mastering is all about. We'll give you an overview of the scrum process. We'll describe the scrum roles of which the scrum master is one. But there are other key roles involve with scrum project work. We'll talk about the key principle of scrum development which is we develop in releases and within the releases we develop in individual sprints where a sprint has a very defined time box.


Then we'll talk about some of the scrum rituals. You're going to hear or you've probably heard terms such as the daily scrum, the sprint review process, the retrospective, and so on. So we'll orient you to the various scrum rituals or processes to be followed in a scrum development project. And we'll talk a little bit about scrum management. There is management process in scrum and, again, there are probably a few terms that you've heard of such as the daily burn down chart, the story burn up chart and so on. That will give you an overview of what scrum management is all about because there is a management process in scrum. And finally, we'll talk about or differentiate the differences between scrum and other agile development processes.


But, first, let's roll up our sleeves and focus on what is scrum. So probably the very hardest thing I had to do in this nugget series is to give a definitive definition of scrum. What is scrum? Is a systems development approach? Yes. Is scrum exclusive for systems development? Absolutely not. Anything and I even hesitate to use the word thing but anything you want to do that requires a level of work typically of a unique variety because scrum is not truly designed for routine day to day production, doing the same thing manufacturing widgets day in day out. That's not scrum. So I would start to say scrum is based on project based work, where a project is a unique undertaking to develop, to deliver, to produce something new and unique.


Does it have to be software? No. Typically, when we discuss scrum and most of the approaches we're gonna discuss in this nugget series are based on software development undertakings. And I really struggle with using the word project because most agilist and most scrum specialist try to differentiate between what we do with scrum approaches and traditional project approaches, and that is very, very true. Scrum is very different than traditional approaches and we'll discuss that in a future nugget. But I will continue to largely call out the work we're doing within scrum as project based work simply because it's unique and it has a goal.


So when I refer to projects, I'm talking about something, some piece of work, something that we're going to do that is unique and has a goal and requires work. So again I have found I use the word project most comfortably. As I say there are other scrumists, agilists who prefer to not use the word project only because the word project takes us into more the traditional mindset. But in the pure textbook definition scrum is project based work often associated with software but not always. You can do anything in a scrum world. So enough with the definition. What is scrum? Scrum is very mush iterative.


If we are to find a single word, in my humble opinion, that defines what scrum is, it's iterative. We do the project in pieces. And in a true sense of scrum we will do a project in many, many, many pieces. Each release that we discussed in the introduction and we'll talk more in this nugget is a part of the project. Within each release we'll have a sprint or a number of sprints that make up a release.


An the sprint is developing a piece of a project. So that's why it's iterative. It's many, many, many pieces. And we'll talk about that aspect throughout this entire nugget series. Another key differentiator of scrum is it's very lightweight. You'll see by the time we finish this nugget series, there is some very sound, some very complete, some very robust definitions of developing working in a scrum environment, but there's not a lot. There is not a lot of memorization, there is not a lot of process, there is not a lot of predefined forms.


As a matter of fact, there are no predefined forms associated with scrum. So it's very lightweight. It's easy to learn. Scrum is very, very easy to learn, but it's also hard to master. I hope by the time we finish this nugget series you have absolutely done all of the learning and are even well on the way to mastering.


As I've already said, it's very simple to understand and it's based on these three principles. Transparent. There is nothing hidden. There's no traditional now the team is gonna go away for a period of time, two weeks, two months, et cetera, et cetera, and we're going to do some work and just trust us. There's none of that.


Everything we do in a scrum environment is extremely transparent and, as we'll discuss in just a moment when we get into the roles, there's going to be a product owner. And the product owner represents the business. And the product owner is part of the scrum team. And the product owner is expected to participate daily in the scrum activity. So if you have your product owner, if you have the business sitting with the team for a significant part of everyday, there is no ability to be non-transparent.


So scrum is designed to be extremely transparent. We want that product owner, we want them involved, we want a feedback, and we want to adapt and adjust which is the flexible and adaptable. And quality is built in. A lot of people, when they look at a scrum process or they first hear of scrum process and says, yeah, that's just the Wild Wild West. We just have a bunch rogue programmers out there writing code as they see fit and calling it scrum. It's absolutely not the case. Quality is built in throughout scrum. Each one of our iterations, each one of our sprints, and each one of our releases has the expectation that we're delivering functional, tested, implementable code. Or if you're interested in using scrum for non-development approach, each sprint results in meaningful results that the business can choose to use at the end of each sprint.


So transparent, nothing is hidden. We want full active participation. We build quality in. It's not the Wild Wild West. It's tested implementable code at every step of the process. And, as we discuss some of the agile process that we're gonna apply continuous build, continuous integration, test driven development. What we deliver in a scrum environment is quality and it's flexible and adaptable.


Because our sprints are short, if we find we made some mistakes, if we find our approach is not correct, if we find we need to fix things at the end of each sprint, we have a retrospective and in the retrospective we have the ability to be flexible and adaptable to improve continuous process improvement.


So with this relatively brief introduction to scrum, I hope I've whetted your appetite on scrum and that you're ready to continue through this introductory nugget and certainly through this entire series to better understand scrum and to be better prepared to take your scrum master certification.


So consistent with the fact that scrum is lightweight and easy to understand, there are five main roles defined in a scrum process. The key role is the scrum master. And I hesitated to say the key role is because most people will suggest the product owner is the key role in a scrum project.


For the sake of this nugget series, I'm saying the key role is the scrum master because that's why we're developing, that's why we're taking this series, is to understand what scrum mastering is all about and to prepare you to become a certified scrum master.


The scrum master is not a project manager. The scrum master is a guide. The scrum master is a facilitator. The scrum master may be a participating team member. The scrum master has no authority, but a lot of influence. I still believe the scrum master is key to the success of scrum processes because without any effective scrum manager filling these roles of the guide, the facilitator, able to work in a non-authoritative manner, but to influence the team and guide the team success, again, I believe the scrum master is certainly a key member of the scrum development team. If not the key as I say, a lot of other proponents of scrum will say the product owner is the key role because the product owner is the person with the authority on what is done.


And that's where the product owner's authority stops. The product owner defines what it is the team is gonna develop. The product owner creates things called user stories. The product owner provides the details around what a user story is. And we'll talk much more about a user story later in the series. But the user story basically, again, identifies the what and the product owner identifies the priority in which the whats are gonna be done. And the product owner provides all of the details that the team needs to complete the whats.


The team has the authority on how they accomplish the what. So the team is the people who work as a self-organizing, self-managing, self-controlled unit. There is no project manager in scrum. There is self-organizing, self-managing team that collectively determine how they're going to complete all of the work that the product owner has identified that needs to be done.


The scrum master guides, facilitates, and influences the team, influence the businesses, and to me one of the key roles of the scrum master is removes the roadblocks to allow the team to get the work done. And these three are really the core team, and they're all participating members. As I said, we have transparency.


The product owner is part of the team. The team does the work. And the scrum master ensures the team works in a scrum-like method and that is literary the core team. We have two other roles identified SME�s, subject matter experts. Subject matter experts are not part of the team. Subject matter experts are called in as needed.


In a utopia world we would not need any SME�s because the product owner is all-knowing, all-seeing, all-wise. In most real life business environments a single person, the product owner, is not all-knowing, all-seeing, all-wise, so therefore, there will be instances where the product owner says, you know, I really don't know that answer, why don't you call Susan? And Susan becomes the SME. And then, finally, we have another key person and that's the business owner. That's the person with the dollars. That's the person with the need.


And the product owner and the business owner may be one person but often not, the business owner is typically manager who has the power and the authority to commit organizational resources, i.e. dollars to the project, and managers don't have the time to sit with the team four hours every day to work on the scrum approaches. So the business owner appoints a product owner who does the day to day interaction with the team. The product owner typically organizationally reports to the business owner. And, typically, the product owner reports to the business owner from a project results viewpoint as well. And that's it. Those are all of the roles associated with scrum. Now, we have an entire nugget that's gonna go through the roles and responsibilities of these team members in much more detail, but at an introductory level these are our scrum roles. And if you'll excuse my drawing, I know I'm not the most artistically talented in the world, this diagram to me represents the concept of releases in sprints.


Overall, this black area, and I deliberately did not draw this as square or regular object because projects are typically not that well defined. There's typically a lot changes, flexibility, well we're not gonna do this little piece here because that's better done inside the project and there's a significant amount of work here that's, again, business process, manual activities, as opposed to everything inside the black object is the product that our scrum team is gonna develop. And the developing this product may take a considerable amount of time. It may take six to 12 months to do all of the work associated with developing that product, taking on six to 12 months delivery as a single delivery is a traditional development project, and we know scrum is not a traditional development project because it's iterative with multiple releases and multiple sprints. So the business owner and the product owner work together to develop a release strategy. And they say this can be release number one and this can be release number two and release number three and so on. So if we deliver this functionality here, there's business value, let's call that a release. And then we augment that with some more business value here. Let's make that a release. So we'll release may be one to two months in length.


And that, again, is far too much timeframe for a traditional scrum approach, so then we take each release and we break it into number of sprints. So this is sprint number one, sprint number two, three, and so on. And these sprints are in very short timeframes, where I am hesitating to tell a defined number for the length of a scrum sprint because there is some flexibility.


But, typically, a scrum sprint is somewhere in the one to four week rage where, again, typically, a lot of projects don't work at the extreme so there's not a lot of sprints that are a week long or not a lot of scrum development approaches that take only one week sprints, nor are there a lot that take as much as four weeks because we lose some of the adaptability and flexibility so most sprints are in the two to three week window. And in each one of these sprints we deliver a little piece of the overall product. And when we combine sprints together, we get a release. And the release gives significant business value and, when we build all of the releases, we get the entire product. Now, a key concept of releases in sprints and scrum approaches in general is when the business owner and the product owner did the original plan this is what they thought the product was gonna look like but partway into it the product vision is going to change and we start to build that piece out there and we start to take this piece out and we build it and we reduce functionality and so on. And in a traditional approach, this is all done through change management and formal approval and formal authorization and work to do all of that. None of that happens in sprint because all of this change is outside of our current sprint. So if the business wants to add more functionality, we'll get to it.


When's that schedule? Oh, that's gonna be in release number six, great. The business decided to remove functionality and that was gonna be done in release number five, awesome. So now, release number five can do this piece over here oops, five not two.


So this is again part of the adaptability and flexibility of using scrum processes is it lets the business adjust and flex and deliver exactly what it is the business needs as business change happens and as the business requirements evolve. And consistent with being lightweight there are very few scrum rituals we need to concern ourselves with. There are four main scrum rituals and I presented this a little out of order. I presented the daily scrum first because my expectation is that's the first ritual you probably have heard off. That's the thing people think of most when they think of scrum development. And that's the daily scrum and this is your 15 minute stand up meeting where the team meets on a daily basis, hence, the term daily, for no more than 15 minutes. And in order to try to keep it to 15 minutes we recommend that this be a stand up meeting. If you're standing up and getting tired on your feet, you're not gonna be as prone to talk as opposed to, if you're sitting in comfy chairs with lots of sweets sitting on the table and some nice fresh coffee at the back, your 15 minutes stand up meeting quickly extends to an hour and a half because people just simply want to enjoy the soft chairs and the donuts and the fresh coffee.


So, idea of the daily scrum, 15 minutes max, stand up, get it done and is what did we do? We do yesterday, what are we gonna do to do today and issues, problems, quick round the table, talk to every team member, awesome, we know what's going on. Joe, can you work with Betty to help Betty accomplish what she's gonna do? Fred, how did this go yesterday, did that approach work? Awesome. Why don't we try that going forward and so on and so on? It's a perpetual process improvement to ensure the team is on track to achieve the objectives of the sprint. The first ritual that we do in scrum, so again literary it should have happened up there, is the planning meeting. And the planning meeting actually is where the business requirements are presented, where the product owner selects the stories that are next most important to the business. Story 15, story 36, story 49, and story 2 are the next most important stories, pieces of business functionality that I want the team to focus on over the next sprint. So part one of the planning meeting is we select the stories.


And when I say we select the stories, the product owner selects the stories based on priority. And in the second half of the planning meeting the team validates that they can accomplish the story selected, that there's enough information at hand, that they understand the stories well enough to do the work, that there's enough time, that the environment is prepared, et cetera, et cetera. So with the planning meeting done, we then start the sprint two to three weeks on average and we have a daily scrum for everyday of those two to three weeks where we ensure that we're still on track for our approach that we've delivered for the sprint.


At the end of the sprint, we do a scrum review, where we represent the results. So business product owner, you asked us to do these stories, we're going to have a little show and tell. We're gonna show you the results, we're gonna prove to you that we achieved everything you asked us to do. Is that acceptance test? Kind of. Presenting the results should be short and sweet. This should not take a lot of time. We do not expect formal Power Point presentations.


It's literary a roll up the sleeves and presents the results. Get confirmation that you have achieved the results, the expectation of the sprint, and declare the sprint done. And then, finally, have a quick retrospective to say, what worked, what didn't work, and start the process improvement.


And the last key aspect to scrum work is there is a scrum management. Like everything else in scrum it's very lightweight. There aren't project management plans, there aren't formal Gantt schedules, there aren't most of the things we typically associate with project management, but there is scrum management at a very lightweight. And probably one of the main scrum management tools is the burn down chart. How well are we doing? Here is a graph for the sprint, day one, day two, through day ten or day 15, depending on whether there are two or three week sprint. Here's our objective. We wanted to do 14 stories. At the end of day one how many stories, at the end of day two, and so on, and we had a little lull in there where we had some complex stories and we're tracking our progress to see if we accomplished the expectations of the scrum.


Talked about stories already. The story curds is where the product owner defines the whats. We don't do a large analysis document. We do a number of story curds. And most people recommend story curds are handwritten, so hopefully, your handwriting is better than mine, on index cards. And this index cards are used with thumbtacks and maintained on a peg board or corkboard. But the story curds are part of the management where we identify the whats that's gonna be required and we combine the story cards on that corkboard to give us the product release backlog.


So here are all of the story cards that are required to satisfy all of the whats. The product owner goes to the product backlog as part of sprint planning and selects the next hire urgency prioritized stories and presents them to the team. We use that to develop the sprint backlog. The sprint backlog is obviously the input to the burn down chart and it identifies the 14 stories that we want to accomplish in the sprint. And the final aspect that we haven't discussed yet in this nugget as part of scrum management is this principle of velocity.


How long does or is a story? How much work is required to complete the story and how much work can the team do in a sprint? So with this concept of velocity we're able to take that sprint backlog, validate that we have the ability to complete all the stories that the business has selected, and we can use our velocity to track how well to ensure the predictability of our burn down chart is allowing us to achieve our expectations of completing the sprint in ten days. And in a nutshell, that's it for scrum.


Scrum is all about developing an agile approach to software development, which leads us to our next discussion point, what is the difference between scrum and agile? So where does agile fit in? Well, my first statement is scrum is agile. Agile to me is a lightweight software development process.


Scrum is a lightweight software development process. The big distinction I make between scrum, and scrum is very focused on the "management", and I will definitely put that in quotation marks and I try to write it in the small of letters as possible and still allow you to read my horrible handwriting because scrum is management light as we've experienced, but scrum is the management process.


It's identifying of the roles. It's identifying the rituals that we're gonna go through. It's identifying of the artifacts we're going to produce. So scrum is a way to develop lightweight software and scrum applies at your project discretion most of the agile development processes for software development such as test driven development. Write the test cases then write the code to ensure that test cases are successful. Ensures we're delivering quality. Where appropriate, scrum supports pair programming.


Scrum absolutely expects that we're gonna do refactoring, that we are going to have technology debt, that we going to have to do process improvement, that, as we add new functionality in future sprints or future releases, that we're gonna break things and we need to do improvement, so we're gonna have refactoring recognizing the technology debt is inevitable in a lightweight incremental iterative software development process. Scrum recognizes the technology debt exists and must be removed through future sprints and future releases and absolutely supports the concept of continuous integration. You complete a piece of code, you check it into the repository, you run the build, and you make sure you didn't break anything. So the distinction between scrum and agile is scrum is one of the agile processes. Scrum, I believe, is one of the most popular and most successful agile processes because scrum has this very small letter, quotation marks management process, and when we apply our scrum processes and other proven agile development techniques, I believe we have an absolute recipe for success.


So in this introductory nugget to the scrum master preparation, we provided a high level overview of scrum. We defined what scrum is. It's a lightweight iterative process with some very light management to help us develop traditional software but any project in an iterative flexible manner. We discussed scrum roles, the scrum master, the product owner, and the team as the three core roles to participate in a scrum project. We talked about releases and sprints combining to deliver the specific requirements of the business. We identified a number of scrum rituals where the daily scrum, the planning meeting, the scrum review, and the scrum retrospective allows us to keep the scrum project under control consistent with scrum management where we provide a very lightweight management approach. And we concluded with a review of scrum is one adaptation, one method of being agile.


So with this introductory nugget concluded, I hope you've remained interested in scrum development that you continue your interest in becoming a scrum master. And I encourage you to continue through the rest of this nugget series and further explore and further understand this exciting world of becoming a scrum master. This concludes our nugget and scrum master preparation. I hope this module has been informative for you. And thank you very much for viewing..

Scrum versus Traditional Development

Scrum Roles

Scrum Meetings

Scrum Artifacts

Scrum Master

Product Vision and Product Backlog

What is done?

Release and Sprint Planning

Scrum Estimating

A Sprint

Daily Scrum

Tracking Progress

Dealing with Changes

The Product Owner

Sprint Review and Retrospective

Backlog Grooming

Writing User Stories

Team and Business Dynamics

Technology and Process Debt

Agile Development Techniques - 1

Agile Development Techniques - 2

Delivering Large Projects with Scrum

Distributed Scrum

Scrum Process Improvement

How to Deal with Organizational Resistance

How to Get Started with Scrum

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus
Entry 15 hrs 27 videos


Training Features

Practice Exams
These practice tests help you review your knowledge and prepare you for exams.

Virtual Lab
Use a virtual environment to reinforce what you are learning and get hands-on experience.

Offline Training
Our iOS and Android mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching
Develop and maintain a study plan with one-to-one assistance from coaches.

Supplemental Files
Files/materials that supplement the video training.

Speed Control
Play videos at a faster or slower pace.

Included in this course
Pick up where you left off watching a video.

Included in this course
Jot down information to refer back to at a later time.

Closed Captions
Follow what the trainers are saying with ease.
Steve Caseley
Nugget trainer since 2004