Scrum Master Exam Prep

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.   

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. 

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.