Professional Scrum™, Professional Scrum Master, PSM, PSM I, etc. is the protected brand of Scrum .org. This course and practice exam is neither endorsed by nor affiliated with Scrum .org.
All the content related to Scrum Guide is taken from scrumguides. org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at http://creativecommons .org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons .org/licenses/by-sa/4.0/.
Need a little extra ‘oomf’ for your prep to pass the Scrum Master exam? Then this is the course for you.
In this course you’ll learn everything you must know in order to pass the Scrum Master exam. I’ve taken the exam objectives and honed them down to just the essentials to pass the exam – nothing more and nothing less. When you complete this course you’ll be well on your way to clearing the Scrum Master certification exam.
In this course you’ll receive:
Complete exam preparedness
Course workbook of all the slides
Vocabulary flashcards for learning all Scrum terms
Comprehensive final exam at the end of the course
4 Professional Development Units if you’re a PMI credential holder (3 technical, 1 leadership)
We are a PMI Registered Education Provider, Instructingcom, LLC: PMI REP #4082. Scrum, like the huddle in Rugby, requires teamwork, adaptability, and great communication. We’ll cover all of these topics in this course.
Enroll today and get working to passing your Scrum Master certification exam.
Welcome to the Scrum Master Exam Cram. I'm Joe Phillips, I'll be your instructor for this course. The Scrum exam is really not a terribly difficult exam to pass, but don't think that it's necessarily easy. You do have to know some terms, how scrum works in any environment, and you'll need to know the different roles. This course is going to walk you through everything that you absolutely must know in order to pass the PSM.
Our goal in this course is you passing the exam so know this first thing, you can do this. Don't be afraid of you've got to go take a test. Actually, you don't have to go anywhere to take this test, you can take the PSM right online. That's our first goal, is you passing the PSM, that's going to be our focus in this course. Our second goal is for you to build a deep understanding of scrum methodologies. You want to be a successful project manager, a successful scrum master so you really have to understand scrum and how it works.
I just want to make sure you have a good understanding of how to navigate this interface. It's really pretty logical, but we get some questions from time to time on, "How do I do certain things?" So, let me show you how this works. Here is another course. This was for the PMP, and in this course, very similar, you can see the lecture. Same background, different shirt, same guy.
In this course, you can see a couple things. Down at the bottom is your player. If we hit that, it's going to play. Here I am talking, right? Let's pause that guy. If you want to back up a little bit, this button, rewind five seconds, or you can fast forward five seconds. If I'm really boring, which happens, the playback rate, you can change all the way up to two times speed. If we watch that, I really talk quickly. Or, if I'm speaking too quickly for you, you can slow it down to a halftime speed. Then you can always move it back to normal speed, one times.
Our whole goal of this course is you passing the PSM exam, so it's important that we understand what we're getting into. Let's talk about the PSM 1 exam.
This exam has 80 questions. They're multiple choice. Some of the questions will be true and false. Some of the questions, you'll have to choose more than one answer. You really have to know the content. You'll take the exam online through Scrum.org. The cost of the exam is $100. It's pretty straight forward here. 80 questions, you'll take it online.
Now, let's get into some good stuff. Let's talk about Scrum and Agile. Agile is a whole bunch of different methodologies for projects that are knowledge or projects where all the requirements aren't well known at the beginning, and there's a lot of different flavors of Agile. Obviously, Scrum's the biggie. That'll be our only focus here, but Agile also includes things like kanban, XP, crystal, lean, and some other different flavors.
Our focus is just on Scrum. So, projects that are good for Scrum, the requirements for what you're building, they're not always known up front. A piece of software's a good example, where you have a lot of changing requirements that as you do the work, you discover new requirements or new features or the customer sees what you've created and so they want, oh this gives me a good idea. Can we add this to the software? It's an Agile framework.
Although our focus will be on Scrum, it's important to understand the history of Scrum for your exam and how this evolved, and the foundation of Scrum is really the Agile Manifesto. The Agile Manifesto is where a bunch of software developers got together, and they described their values as software developers and management in getting things done where we don't always know all the requirements.
If you think about building a house, when we go to build a house, we can define everything that's going to happen in that project. So we can go all the way down to one of the cabinets in the kitchen or even the handles on the cabinets. We can be very precise. When we're developing a piece of software, though, we don't always know exactly what we need in that software. We have a lot of the requirements, but those might change, where in a predictive project, a construction project, it's a little bit more hard to change while we're in motion. So Agile welcomes change, expects change.
There are some other things that you need to know about Scrum for your exam. So when should I use Scrum? Well, we should use Scrum if we have a lot of unknowns. Many unknowns, lots of things up in the air, so we don't exactly know all the requirements, we don't exactly know what the icon should look like or what the screen should look like or what exactly everything this piece of software's going to do.
So we have a lot of unknowns. Complex projects are difficult to define requirements up front.
In this lecture we'll walk through the basics of Scrum. We will look at the three pillars of scrum, the TIA, the transparency, the inspection, and the adaption. And, that got us into what's called the ceremony, the four ceremonies in adaption. There we have sprint planning, our daily scrum, and then we have our sprint review, and the sprint retrospective. We'll look at each of those in much more detail, coming up.
We talked about a lot of stuff in this first section. We talked about the professional scrum master exam, which you're going to pass. Talked about the goals of this course, that's you passing the exam, becoming a better scrum master, and being able to speak intelligently about scrum. We looked at the Agile Manifesto and those four values, where we talked about individuals and interactions, working software, customer collaboration, and then responding to change. Those are four values you'll need to know for your exam.
We also compared and contrast our knowledge work projects versus those more industrial projects or predictive projects. Then we talked a little bit about the fat lies that people have about scrum, so don't get tripped up by those. In this section, we built a good foundation of scrum. We know scrum is a framework for complex, adaptive problems. That we have a problem and then we adapt to it and we overcome. We looked a little bit about the theory of scrum, an empirical process. Remember empirical processes means, I have experience and I have knowledge, and I have an understanding of the DOD, where we want to go, the definition of done.
Scrum Project Timeline
In this section, we're going to go through a timeline of a scrum project. This is really probably our really meatiest, most term-packed section of the whole course. You really want to know what's happening in this section of these terms for your PSM exam.
So, in this section, we're going to talk about how do we get from beginning to the end of a scrum project, and there's a lot of moving pieces, a lot of rules of how you move along. So you really want to know these rules and know how a scrum project moves through the timeline to get to the end result, to get to that value for the customer.
Now let's look at the timeline for a scrum project. Let's hop right in here.
In the product backlog, we'll also include things like functional and non-functional requirements. Non-functional requirements are things like stability and up-time and security. Things that you really can't touch and feel. We'll also have things in there like the architecture. So sometimes those items have to be prioritized and that's why the scrum team, the developers are involved with the product owner, because the product owner isn't necessarily a developer. They're in charge of representing the customers, the key stakeholders, of the business, so they are really familiar with what the business wants, but the team needs to be there because they're familiar with what has to part of backlog in order to create those things that the business wants.
There are some terms you'll want to know that precede the sprint, especially when a scrum project is just getting started. You want to know these four terms and their characteristics.
The product backlog that we just saw, that's made up of all the stories, and it's prioritized by the product owner and the development team. So the product backlog is prioritized. Technically, the product owner, they have the responsibility for keeping that prioritized. When new items, new requirements come into the project, the product owner will prioritize those items in the product backlog. They aren't just necessarily added to the bottom. They could be up top or right in the middle or scattered all over. The priorities happen whenever the product owner wants, but they don't affect what's currently in motion, what's in the current spread.
Now let's talk about the Sprint activities, about getting stuff done. That's our goal is to create value by creating things.
So our Sprint activities, we talked about the Sprint Planning Meeting. That's where the team and the product owner, they collaborate and they talk about how much work can the development team take on in the next Sprint. So it's based on that prioritized Product Backlog. We're going to pull items out of the backlog based on the team's capacity and then that sets us up for the Sprint in the Sprint Backlog, the list of tasks and requirements the team has to create in order to hit the goal of the Sprint.
The idea of ceremonies, you think of a formal event, right? There's rules and there's decorum, so it's a ceremony. It's a process. Well, here in our Scrum project, we also have some ceremonies. There are four ceremonies you need to know for your exam, and you've already seen these, so we're just going to nail them down really tight for your passing of the PSM.
The first one is the Sprint planning meeting, and we're going to look at the details of each of these. Sprint planning meeting, the Daily Scrum, the Sprint review meeting, and the retrospective. Those are the four ceremonies, and there are some more characteristics you need to know.
Great job, you did it, I told you it wasn't a terribly long section but it's an important section. In this section, we talked about the timeline of sprint activities. That's key stuff you want to know for your exam. Not a lot of moving parts here, there's not a ton of things happening. It's the same four ceremonies, like my 4-H days, to get to the end of the sprint. To get to the end of the project is our goal and to create value, that's our primary goal.
A quick recap, I know you know this. What happens first, say it out loud or you can say it in your mind's eye if you want. What happens first, we start with the product backlog, and then we have the ceremony called the sprint planning meeting where the team is determining capacity based on the prioritized product backlog. The user stories the team selects, that goes into the sprint backlog and that's how the team defines their task that they'll do. Then, that takes us into our sprint. Every day you have a daily scrum and it will last for 15 minutes, it's time boxed.
Scrum Roles and Responsibilities
Welcome to section three in our course on you passing the professional scrum master exam. So one of the things that you have to know as you go into the exam, are what are the characteristics of the roles in a scrum project?
So there are really only three roles in a scrum project. We have the scrum master, that'll be you. You have the development team, and you have the product owner. Those are the only three roles. There's not testers, there's not technical writers or trainers, nope. All of those folks are part of the development team.
So in this section, it's all we're gonna focus on are those three roles. And then what are the responsibilities for each of those roles, that's what you'll be tested on. So you'll need to know the rules and some characteristics of those three roles and that's what I've created for you in this section.
So keep after it, let's hop in and get to work and talk about these roles that you'll be tested on for your PSM exam.
Let's talk about first the Scrum team. These are the folks that are the core of your team. Sometimes we just call them the development team, but really technically the development team are developers. Your Scrum team is really all of the project team members.
Let's take a look here. As I've said, there are only three roles in your Scrum project. You don't create new titles or new roles, because that really is harmful to the unity of the team. You wanna keep things pretty shallow, pretty flat. You want multiple layers to your team. It's also not compatible with the Scrum philosophy that you'll be tested on.
The idea of the Scrum team refers to all the project team members, so the product owner, the Scrum master and the development team. You can see that's what I was talking about, that all of those people are part of the Scrum team. The development team are the developers. The stakeholders, they can be involved in the project, but they are not considered internal to the project. So, imagine that you're creating a piece of software and the product owner is representing the business. The in-users, they are stakeholders, but they're not part of the Scrum team. They're external to the project.
Now let's talk about the product owner. The product owner represents the business. They represent the end-users or the customers. They have to be kind of an intermediary between the people they represent, the business, the customers, the end-users and the development team. They have to have a clear understanding of what the customer wants in order to write those user stories, and then to be able to interact with the development team when it comes to clarifications and questions.
Some particulars you want to know about the product owner. This is one person. It's not a committee. The product owner is one person. Now you notice I immediately say, "Well, it can be a committee." You can have a committee, but one person represents that committee. For your exam, it's one person. If there's a committee like a technical assessment board or a technical review board or a portfolio management board, that's great, but one person represents the committee. So you can have a committee, but it's not a whole committee serving the role of the product owner.
Now let's talk about the scrum master. So this'll really be important for your exam and for your career if that's your goal, to be a successful scrum master. The scrum master has to fully understand scrum, that's the point of this course and that's your goal in passing the PSM to show you understand scrum. The scrum master is a coach. They're coaching the team and coaching the product owner to ensure that everybody is following the correct processes. So for example the daily scrum. Although the scrum master does not have to attend, they often do to make certain that people are following the rules of that time boxed 15 minute meeting.
It is a management position, but they're managing the scrum process rather than people. Sometimes the scrum master is seen as a servant leader, meaning that I as a scrum master I get people what they need. I take care of problems, I remove impediments, I make certain the team has the resources they need and the information they need to get things done. The scrum master also has a really important responsibility, and that's to lead the organization in its efforts to adopt scrum.
We have talked about the product owner, the scrum master. Now let's talk about the development team. Of course the development team, we're talking about developers, people coding, people developing, testing, doing their cross-functional roles, getting things done. The development team, these are experts that are responsible for getting the items done in the backlog. They're cross-functional and self-organized. Cross-functional, they can do more than one role. Self-organized, they work out amongst themselves who will do what. The scrum master does not tell these individuals what to do.
The whole development team is responsible and accountable for the items in the Sprint Backlog. No one person owns any task. The whole development team is responsible. The development team is responsible for delivering that final product, and they do this through step-by-step increments. Remember the product backlog is prioritized. They take a chunk of work, becomes the Sprint Backlog. That creates an increment. The increment passes the review, then it goes into a potentially releasable item. That's how we go from the product backlog all the way to the deliverable.
Now let's talk about some other roles you need to know for a Scrum project. I'm just kidding. There aren't any other roles. You have the Scrum team, which is made up of what three roles? Scrum master, product owner, and the development team, so when it comes to other roles, Scrum does not allow this. You don't have other roles in a Scrum project. Members have the same role and title: project owner, Scrum master, or development team member. We don't have different titles or roles in the development team. You don't have testers and technical writers and so on. It's people have the same specific role. You're a product owner, you're a Scrum master, or a development team member. Different titles or roles are going to shift focus to what tasks go to specific roles, and that may cause the team to not pay enough attention to the final product. That also begins to shift blame or responsibility. The whole team is responsible for the outputs that are created in the development team. Development team is responsible for the development team and what they create.
ou are making fantastic progress. You have knocked out some really big stuff here as you prepare to pass your PSM Exam. So important that you continue this course and finish this course. I promise you I'm showing you exactly what you need to know to pass the Professional Scrum Master Exam. Now, in this section we talked about the roles that you'll encounter in a Scrum project and there are only three roles. So, three roles to remember.
Obviously, Scrum Master. Remember the Scrum Master is more of a coach and they remove impediments and they make certain that people are following the rules of Scrum. So, a Scrum Master has to really know and understand and embrace how Scrum works. They're also responsible for being an advocate for Scrum, for the organization, to show the success of Scrum and to help Scrum grow in the organization.
In this section, we're going to drill down just a little bit deeper into the specifics of the scrum events, the things that you'll have to do as a scrum master in a scrum project.
So, in this section, we're going to talk about the sprint planning in a lot more detail. We'll look at the product backlog and how that gets prioritized and how the product owner works with the team to prioritize those items in the product backlog. Specifically, I'm talking about the user stories, where the team will select a chunk of that during sprint planning.
We'll look at the sprint backlog and what happens during the sprint. We'll take another look at that daily scrum and then the sprint review, where the team will demonstrate what they've created. Then we'll talk about the sprint retrospective.
Let's hop in here and talk about the nature of Scrum Events. At the heart of Scrum is your Sprint. Recall that a Sprint is between one and four weeks, but four weeks is pretty typical, and that's where the development team is actually creating the user stories for the product, that the project is creating.
Each Scrum Project is a set of Sprints. The Sprints last for one to four weeks. So, the more Sprints that you have, the longer your project is going to be. Whether that's one week, or two weeks, or four weeks.
So, we often talk about, a Sprint is an iteration. It's an iteration of the set of processes, to create an increment which appends to the work you've already done. The deliverables from previous Sprints. So, each Scrum Project is a set of Sprint Events. A Sprint is the container for the other four events.
Let's talk about a concept that's really important. And I've mentioned it several times throughout our course already, and that's the idea of something being time boxed. A time box is just where we have a meeting or an event, and we know it's going to be X amount of hours. So, a good example of a time box, think about your favorite movie, or think about your least favorite movie. Any movie is typically between 90 minutes and two hours. Some are little longer, some are a little shorter. But generally we say about two hours is the movie experience, all right? Well, in sprint we have very specific time boxes, that stay in those parameters, they're not shorter or longer. We define what the time box is, and everyone agrees upon it, and that's part of the rules. So a time box is just the fixed period of time. The daily scrum, 15 minutes. Keeps things popping. Keeps it moving. And we quickly get through, what did we do yesterday? What am I going to do today? What are the impediments? If there needs to be along drawn out conversation, that doesn't fit in the 15 minutes. So the team will take that outside of the meeting and have that conversation. The people that are involved in that longer conversation.
Now let's talk about running a sprint. We know that a sprint is a four-week time box container where we do specific events. At the heart of that is the development. Let's take a look at all of these bits and how it flows in a sprint.
We begin the sprint with sprint planning, and that's where the team is going to decide what products from the product backlog will go into the sprint backlog. So, sprint planning is our first event.
Then you can see we have the activities. That's actually doing the work, doing the development with the development team. The product owner is interacting with the customers and the development team. The scrum master is making sure everyone follows the rules of scrum.
While Scrum projects are much more loose, or not as detailed-planned, as predictive projects, there is a need for the Development Team to plan out their sprints. We'll examine sprint planning in this lecture.
I've mentioned the daily scrum several times. Well, there are some specifics that you want to know about the daily scrum for your exam. You know that it's a 15 minute for the development team. It helps the team synchronize their work over the next 24 hours. What did I do yesterday, what am I going to do today, are there any impediments? Those are the three questions. So any obstacles, impediments, roadblocks, that's all the same thing as part of our three questions. The team will look at what progress have we done towards the sprint goal, not the whole product backlog, just the items that we've taken on in this sprint.
It also helps the team to do some forecasting. So how likely are we to get all these items done that we've taken on? Ideally you do this at the same place and time every day throughout your whole sprint. It's for a development team, it's not a status meeting. The CEO and your stakeholders and customers ... No. They don't come to this meeting. It's primarily for the development team, they're required. It's a good idea to have a sprint board, or a wall chart to be visible where you have this meeting every day, so the team can look up at that wall chart and get clarity, ask questions, look at what items are in motion. So it's a good idea to have that.
At the end of a Sprint, we have the Sprint Review. This is an opportunity for the team to demonstrate what they've done in this Sprint. So, it shows the results of their work. It's a four hour meeting for a one-month Sprint. If your Sprints are shorter, you would adjust that timeframe accordingly. You don't have as much to show. It's for the Scrum Team and other stakeholders. So, the Product Owner, the Scrum Master and maybe your key stakeholders or your customers, they can see progress. You want to present, but also inspect the "Done" items. So, it's a demo. Look what we've created, look what we've done in this iteration. It's an opportunity for the stakeholders to give feedback and probably some change requests and those change requests will go into the Product Backlog where the Product Owner will prioritize them.
fter the sprint review, we'll move into the sprint retrospective. The retrospective is a lessons learned opportunity. It's attended by the product owner, the scrum master, and the development team. And we're really focusing on what worked and what didn't work. What needs improvement. So, in a predictive project, we often get to the end of the project and we do a project post-mortem, a lessons learned, of okay, what didn't work here? But what do we do with that information? I can't apply it now. The project's done. Well in scrum, the retrospective is an opportunity to take what we've learned and apply it to the next sprint, so we're in motion. So that is the point of the retrospective. It's a three hour meeting for a four week sprint, for a one month sprint. After the sprint review, and before the next sprint planning, it's sandwiched between those two items. Remember we're iteration, we go through the same processes. It's usually required, but optional for the product owner and the scrum master. Oh, let's do that over.
You know that the product owner is responsible for the product backlog. They're the individual that has to prioritize the user stories and the product backlog. That prioritization is sometimes called the Product Backlog Grooming. So it's when the product owner reviews and revises the items in the backlog. So to give more detail on items, creating estimates, ordering the item. Prioritization. The product owner is the person that's responsible for prioritizing those but the development team is really the collective role of creating those estimates.
The product owner really can't say, "Well this is only two story points." And the team will say, "No, that's, that's gotta be like eight." So the development team is the one that has the power over creating the estimates for how much effort is needed for those user stories in the spread. So know that for your exam. When we talk about product backlog grooming, it's really ... There's a difference we need to know between grooming and those other scrum events. The scrum events are time-boxed. Our spread planning, the spread itself, the retrospective, the daily scrum and the demo.
While in Scrum, we really do not have that concept. We don't have to do the forward pass and the backward pass and all that business. However, in Scrum, there is a term called slack. Slack in Scrum is totally different than what we have in a predicted project. Slack in Scrum is an opportunity for the team to take a break before you start the next sprint, but there are some rules here we need to look at.
First off, it really doesn't matter how much the development team works. What matters is that they are creating deliverables, so it's what's produced is what's most important. In other words, if you have this big cloud of activity, but nothing's getting done, just because you're busy, doesn't mean you're producing. It's the producing, the results of the work is what's most important.
The team should be product-oriented, not activity oriented, not just looking busy, actually create stuff. That's what's the value. So when we think about the team, we are limiting the work time to a reasonable amount. Four weeks is pretty reasonable, but it's good to have some frequent off times, so maybe two or three days between sprints that are already planned out. It's recommended that after every two sprints, after eight weeks of work, then you take a little break and kind of catch your breath. That might be three days where you go to a workshop or you read some articles or you just get to catch your breath a little bit and clean up some things. It's a little break between sprints, so it's a day, two or three to recharge your batteries.
Great job, you did it. You've reached the end of this section. We talked all about the particulars of the different scrum events. Really important for passing your exam.
So we talked about the sprint planning and all the activity that goes into sprint planning. And then we looked at the product backlog and the sprint backlog and how that sets us up, based on our capacity for the current sprint. Those items in the sprint backlog, we have the task, where we estimate the duration. That's also part of that self-organization, where the team decides who'll do what. Now although an individual may take on a specific task, they don't own it. The whole team owns everything. They're responsible for everything in that sprint.
You're done. You've reached the last section of this course. So you can knock this section out, you'll be well prepared to pass the PSM.
I want to take moment remind you of the really essential fact that I've applied to my life, I think that you can apply in yours. And that's simply what one person has done, someone can do too. Now why there may be some really peak things like athletes or marathon runners or some really, really singular amazing events. We see those records broken from time to time. Well, to pass this exam, lots of people have passed this exam. It's not a zero-sum reward where only one person can win. Lots of people can do it. If I've done it, I know that you can do it too.
Now, in this course I have focused only on the objectives for the PSM exam. I know you can do this because I'm teaching you exactly what you're going to be tested on. So really dig into the material. You might want to take some time when you're done with this section and go back through and review. And make sure that you're answering all of the questions and understanding all of the questions in the final exam that you'll do after we finish this section.
A term that you're familiar with because I've talked an awful lot about it throughout this course is the product backlog. The product backlog is an ordered list of all of the requirements. The items are written in user stories by the product owner. We want those user stories to be just simple business language that everyone can understand. We don't have to get in all the technical jargon, just write what the goal is of that requirement. Typically, they're written as a role, I want this function so that I get this value. That's a little formula for user stories. They don't always have to be like that, but that's pretty typical. User stories then are assigned story points. Remember story points is a sizing, so this one's worth ten because it's really big, and this one's really tiny, so it's worth one. It's kind of like an extra large all the way down to extra small. There's a little thing that I like to do. It's called T-shirt sizing. Is this an extra large T-shirt, or is this an extra small T-shirt? That helps people get the idea and to get moving and sizing those story points. That's what's done by the development team as part of sprint planning.
Recall that once we have a chunk of items to do in the next Sprint, that becomes our Sprint backlog. The Sprint backlog is created during Sprint planning. It's the very first event in a Sprint. The backlog really has three items you need to know for your exam.
It's the number of items, a listing of items that the team will accomplish in this Sprint. It has our Sprint Goal. Remember that's just a quick narrative to define what we're aiming to do in this Sprint. So, when we get to our demo, we can show we've hit the Sprint Goal, and then we have a detailed plan for the delivery of those items. So, who will do what and when? So, remember when we had some dependencies, and successors, and predecessors for those items. Things that have to be done in a particular order. Who's responsible? The whole development team is responsible. Even though one person may take on a task, the whole development team is responsible.
The increment is what the team creates. So sometimes we think about increment of time, but we're also to think about an increment as a deliverable. The increment is what's appended to the work we've already done. So, back to me little cards here.
So, this is done, it appends to it, and the next one and so on, like a little train. So, the product increment is the outcome of an iteration. So technically, a sprint is a iteration because you're doing the same things, the same activities, the same framework to create new increments what we're adding to what's already been done. So, don't get tripped up on iteration versus the increment.
I guarantee you on your exam you will see the Definition of Done. The D-O-D. So we really wanna nail down what is the Definition of Done. Our first rule is that everyone has to be in agreement on what constitutes done. So the Definition of Done, you wanna agree upon that, you have a discussion early in the project so that future increments are releasable. Now over time, the team will improve upon what constitutes Done. So you get a refinement to the DOD. So over time that will happen.
If you have multiple Scrum teams on a single project, so it might not be possible for everyone to have the same DOD because they might be working on different applications, or what I mean by that is different disciplines. So you might have instructional designers. You might have technical writers. You might have the developers. You might have the database folks. Where the DOD wouldn't be universal to the type of work that each of those teams are doing.
Now, let's talk about monitoring project progress. Everyone wants to know, when is this going to be done? When will all of the items in the product backlog equate to everything that is released to the users, to our customers, to the business, what have you? Monitoring project progress is a way that we can see how quickly the team is moving through all of the requirements in the product backlog. Allows us to do some forecasting. The product owner, not the scrum master, the product owner is responsible for monitoring the overall progress of the project. You want to do this at least once during the Sprint Review. The product owner determines how much work is left, and compares it to how much work the team has done in previous Sprints. This allows the product owner to do some forecasting of when we're going to get done with the project. And then everyone should have access to this information. We call that the information radiator. You put it up on a poster where everybody can see it, so it's a central point of information.
Welcome back. We've talked about measuring the progress for the whole project, but we can hone that down a little bit and talk about measuring our Sprint progress. We want to monitor the progress of each Sprint through each Sprint's life, two weeks or four weeks. This is the responsibility of the Development Team, and you do this every day in the Daily Scrum. Based on our Daily Scrum, what's been done, what am I working on, when do I think it's going to be done, those types of conversations, that helps the team have a realization, are we going to reach our Sprint goal? Are we going to be able to complete everything in that Sprint Backlog? If we are, great. If not, we need to get the product owner involved and talk about the likelihood of hitting our Sprint goal. That is a tough conversation.
Monitoring the Sprint progress, though, we can use a Sprint board. Remember the Sprint board? We can have that what's to do, what's doing, and what's done. We could add to that Sprint board a burn down chart for this Sprint based on all the items in our Sprint backlog. We can have our Sprint goal, and then you could also do that Kanban chart of user stories where you're moving them left to right. A Sprint board is used for transparency, one of our three pillars of scrum. All right, great job. Keep moving forward.
Great job, you did it. You reached the end of this section. We talked all about the different artifacts for scrum. So we took a look at the product backlog, the sprint backlog. We looked at a burn down and a burn up chart. We talked about the sprint board, about being visual, about being transparent with our information, allows us to do some forecasting.we also looked at our velocity and then that allows us to do forecasting when the project is going to be done. A lot of information in this section, I know it was a quick section, but this is exactly what you need as you go in to pass your PSM. So I'm really proud of you, you've reached the end of this section, which also means you've reached the end of the bulk of the course. So I'm really happy, just a couple more items to wrap up and you'll be on your way to passing the PSM. Keep moving forward.
Congratulations! You did it. You've done something that a lot of people have not done, and that's to not only start the course, but to finish the course. Should be really happy with your progress. So you have looked at the entire exam objectives to pass the PSM. Are you ready to pass the PSM? I mean just don't take the PSM, you're going to pass the PSM. You can do this.
Now you might wanna take some time and make certain that you know your vocabulary. Remember those three by five cards? Well you're going to write the term on one side, and the definition on the other. Yes you can just hit print on the vocabulary items all the way back from lecture one and use that, but you really wanna learn these, write them out. Because writing these out, yes it's painful, but writing them out by hand will help you learn the terms as you create the flashcards. And then every day, buzz through those flashcards. This is so important. If you know the vocabulary, you're better prepared to pass the exam.
This 80-question comprehensive exam will yest your knowledge of Scrum practices.