Pass Scrum PSM II Exam in First Attempt Easily

Intro To The Course

1. What Is The Goal (Product Goal) Of This Course?

Hello and welcome. As I usually do, I'd like to take a moment and talk about the goal of this course—the primary purpose. It is about helping students who are already PSM-I certified become PSM-II certified and go to the next level. Professional Scrum Master certifications are issued by Scrum. org and are highly valued by the agile community. with the professional scrum master. At Level 2 of the certificate, you demonstrate an advanced level of scrum mastery. And to achieve that, you have to expand your Scrum knowledge. And this is where my course comes in. So I designed this course while keeping in mind that you will attempt the PSM II exam. However, if your goal is not to pass the exam, you just want to expand your knowledge and align it with the most current information on the Scrum framework. This course will do the job as well. Since we are on the topic of goals, let's talk in the context of Scrum. So my course is the product. I have a product vision. My product vision is to assist 100 people in becoming level 2 professional Scrum Masters. This will bring a positive change in their careers—new job opportunities, maybe promotions, an increase in salary—but also make people feel good about their accomplishments. My product goal, and this is the goal of this course, is to help people who are already PSM I certified pass the PSM II exam and get certified for that as a result. Next, the sprint goals. Basically, the goals of my lectures are the spring semester goals. Each lecture serves a specific purpose. It teaches a concept or concepts that move the students closer to the product goal. These goals helped me enormously while I was creating the course, while I was deciding what sections and lectures I should include, and when I had to make a decision to remove something, I asked myself, "Is it going to help my students get closer to the product goal? closer to Let's add it now. Let's skip it and move on. And these goals helped me to stay focused during the product development. It took me several months. I had ups and downs, but they kept the goals in my mind while I was working. This is why setting clear goals is one of the fundamental principles of Scrum, as you will learn in the advanced section of the course. Now that we know the goal of this course, let's take a look at the road map to success. If you've taken my PSM I or PSP I courses, you know that I always include a road map to success. So, let's take a look in the next video. Thank you for watching and stay purposeful. You.

2. Roadmap to Success: How To Conquer The PSM II Exam

Welcome to the Roadmap to Success! How to conquer the PSM II exam First, we start with the introduction session. We will talk about basic information about the exam and what to expect. But there is also a lecture called Fast Learning. I'll ask you to check the resources there and download them on your device. These are the recaps—the most important points from the course. You need to go over them more than once. Some students prefer to print them out. Others prefer to listen to the recaps instead. This is why I've attached the audio version. The next section is about refreshing your fundamental Scrum and Agile knowledge. Basically, this section is in the my PSM and PSP 1 courses. It is the same, with slight changes. so it is a better fit with this course. And some students might think that this is an advanced course. Why are you giving me PSM One content? Please let me explain. As I said, this course is designed to help PSM One holders get PSM II certified. Honestly, if your score on the PSM One exam is around 86%–87%, that means there are some knowledge gaps we need to fill in. The second reason is time. Maybe you have a very high score in PSM—198 percent, maybe 100%. Great. Good job. But when did you get certified? Is it before or after the release of the latest version of the Scrum Guide? Scrum is constantly evolving, so we need to get you up to speed with the changes. And after that, move to the PSM II material. If you are already a student of mine and you recently passed PSM I, you have a good score. Then you can just do the recaps. There's no need to go through the entire section. Simply said, we need a strong foundation to build on. Next up are professionals from Master Advanced. Here we will master the PSM's II knowledge areas. This is the biggest section of the course. We will do two things. We will expand what you already know and learn new concepts. Of course, some of the topics we will talk about are empiricism and values The Scrum Master's misconceptions, good stances, how the Scrum Master serves the organization, and the product owner of the Scrum team's fundamental Scrum principles for conflict resolution are all very interesting. Emergent architecture key concepts revolve around scaling, velocity, value delivery skills within the team, and more. Next, how to approach the PSM exam This is a short section. I give you my top tips on what to do and what not to do during the exam. By the way, there is a PDF for that as well. It's a quick checklist. I also share with you helpful resources, not just reading materials but also practice exam questions. By the way, all of the resources I recommend are free, so you don't need to buy anything else. Next PSM. two practice questions. This is the exam simulator. Basically, you will have 90 minutes to answer 30 questions for an 85% passing score. It is just like the real exam. I wrote the questions myself. This is not an easy thing to do, but it will definitely help your preparation. I ask you to do the exam multiple times and study the feedback you need to achieve a 100% score. Once you do everything I suggest, you make an attempt at PSM II. You will receive an assessment password, activate the exam, and you will have 90 minutes to demonstrate your knowledge. Once the time box expires or you click Finish the Exam, you will immediately see your score. Do not forget to share your achievements with me. It would make me very, very happy if you'd never studied another course for me. I would like to say a few words about my teaching method. I use a specific framework for my lectures: introduce, teach, recap. I do recaps after each lecture with the most important points. And also, I do general recaps every four lectures or so. one little change in the advanced section of the course. I give you action items before recapping most of the lectures. Most of them are nice articles. Sometimes it is a white-paper blog post. It is very important that you do not skip those. As for the recaps, it might sound too repetitive, but I helped over 1000 PSM One and PSP One students get certified. And the feedback I got from them regarding the recaps is great. They love it. My goal is to make learning for you easier and as effortless as possible. All right. That was the roadmap to success. you for watching and stay purposeful.

3. PSM II - Exam Details

Let's talk about the PSM II exam details. First of all, the difficulty It is advanced. The exam is not easy by any standards. You need to be well prepared. This course will help you with that. You will have 90 minutes to answer 30 questions. Partial credit is provided on some questions. Not all, but some. The questions are three types: multiple choice, multiple answer, and true or false. The exam is in English, and the passing score is 85%. I made some calculations, and if we answer five questions incorrectly, our score becomes 83.3%. That means we fail. If we answer four questions incorrectly, our score is 86.6%. This means we pass. Maybe we can still pass with five incorrect answers if we get some partial credit. So the percentage equals or is above 85%. But let's keep it simple. To pass, we should not make more than four mistakes in one attempt. We have to pay $250. As you can see, it is more expensive than PSM I. What I like about the Scrum certificates is that they do not expire. This applies to PSM II as well. There aren't any prerequisites whatsoever. You can ban attempts at any time. You do not need to attempt official courses or anything special. Now, a quick reminder of the technical aspects of how to purchase You go to Scrum.org. Go to the Certifications tab and choose professional scrum. Master. A page will load with three certifications. PSM I, PSM II, and PSM III We are going to attack PSM II. Click the Buy button and follow the steps. Once the transaction is successful, you will receive an assessment password in your email. These passwords do not expire. You can purchase now and activate it within one month if you'd like. Once you are ready to pass the exam again, go to Certifications, Professional Master, PSM II Assessment, and click the Start button. If you are logged in, you will be taken to a page that requires the assessment password you've received via email. Upon purchase, enter the password and click Start. There will be another confirmation, and the exam begins. You've got 19 minutes to demonstrate your knowledge. All right, this is what I wanted to share with you regarding the exam. Now, let's do a quick recap. 90 minutes. 30 questions. Three types of questions exist: multiple choice, multiple answer, and true or false. 85% passing score, no expiration. $250 per exam. Difficulty advanced. Thank you for watching and stay purposeful.

Hide

Agile & Scrum - Refresh Your Knowledge (PSM I)

1. Intro

Welcome to the second section of the program. As it says in our Roadmap, this is the section where we will refresh your Scrum and Agile knowledge. In this way, you will get prepared for the advanced section of this course, which is the next one. More specifically, we will talk about the Scrum framework, its rules, three sets of accountabilities, events, artifacts, and their commitments. There's also the difference between agile and waterfall-approved development, the difference between product management and project management, and, of course, a lot more. If you are a student of my PSM I or PSP I course, you should know that the content is the same. I've just made changes to the videos to make them better tailored to this PSM Two course. As I said in the video about the roadmap to success, if you've recently passed PSM One, you can just watch the general recap inside this section. This will be quick. It will not take a lot of time. Download the PDF file with the key concepts as well. Maybe print it out. Some students said that it was helpful. Honestly, PSM II is a difficult exam. This is why I encourage you to go over this section. I do not want to leave anything to chance. I am committed to helping you pass the PSMTWO exam in the best way I can. I cannot guarantee you will pass on the first try. Nobody can. But what I guarantee is that I will do my best as a teacher to help you get there. Thank you for watching and stay purposeful.

2. Agile vs Waterfall

Now, to explain Agile to the best of my ability, I would ask you to think about an IT project for a moment. Generally, we can choose one of the two main approaches to management and development. The first one is predictive, and the second one is adaptive. Let's take a close look at the predictive approach. You can also call it a plan-focused or plan-driven approach. What usually happens is we create a big plan at the very beginning of the project and then try to follow it as best as we can. The project has several phases. For example, analyze, design, code, integrate, test, and maintain. This is one big iteration. And please remember this word because I will come back to it later. Very often, these faces last for a few months each. This approach is still used, and it is still effective for certain types of projects. When the work, for example, is predictable, we do not have to do a lot of changes. We just follow the plan. For example, if you're building a house, you know the exact steps. You've done it many times, right? There isn't uncertainty, and so on. But what is the problem here if we apply this approach to an IT project? In fact, it's more than just one problem. There are many problems, but I want to focus on two big ones. First, even though we have a well-written, detailed plan, chances are we won't be able to build what the customer expects. This is not because we are not going to follow the plan, but because the customer is not completely aware of what they want. Exactly. They need to see the product first, and after that they will come up with ideas, come up with more features, and so on. This is a general observation in the IT space, but I have been working in an Agile company for more than five years, and my experience confirms it. Second, we might be developing the project for several months or maybe years without receiving feedback from the end users. This is bad. There is a study that shows that 45% of the features we build into a software product are never used. Can you imagine the waste we're talking about here? Now, let's talk about the second approach, where we have an adaptive life cycle of the project. First, we do not follow a detailed plan. No, we get the customer requirements and build a very small product. We show it to the customer, and then the customer gives us feedback. We collect that feedback and, based on it, we create a second version of the same product. We are adding a little more. We ask the customer to review it and provide more feedback. We collected and built a third version of the product. The good news is that even the very first version of the software product can be used by the end user. So we have the opportunity to collect feedback from them as well. You can see there is a loop going on here—a feedback loop. I've said it's a small product. But there is a term that we use. It's called an increment. Now the question is, how long does it take to create an increment? Well, that would depend on the agile framework method of framework. For example, in Scrum, which is an Agile framework, the maximum duration of a sprint is one month. Very often, that period is two weeks. So we have a two-week sprint. So what we're doing here is that we are building the software product incrementally. This allows us to build with very little to no deviation from what the customer expects. because Agile relies on feedback. This is why we call it an adaptive approach. This is the core of Agile. This is agile. And if you ask me, Vladimir, explain to me what Agile is. With just one word, I would say adaptation, which by the way is one of the three pillars of Scrum that holds. The other two are transparency and inspection. And now, if you read the Agile Manifesto, individuals and interactions overtake processes and tools. working software over comprehensive documentation. Customer collaboration over conflict negotiation, responding to change over following a plan You can see how the sentences on the right relate to the plan-focused approach, which by the way is mostly known as waterfall. Besides incremental development, as I've said, we are adding a little more to the product every time with one increment at a time. Agile also uses iterative development. Do you remember how I told you at the beginning of the video that the lifecycle of the plan focus approaches one big iteration? This refers to the development processes: analyze, design, code, integrate, and so on. In the Agile frameworks and methods that use the time-boxing concept and use sprints, we go through all these phases in one iteration, in one sprint. For example, a two-week sprint, or three weeks, or four weeks—it doesn't matter. Why is that? because we want to create a releasable increment. Remember, based on that increment, we received feedback. So the increment must be 100% done. It must be usable. As you can see, Agile is more than just a mindset or just doing daily standups or being flexible, and so on. Now, Agile needs systems, frameworks, or methodologies that support the agile principles. And this is why we have Scrum. We have extreme programming, we have DSDM (dynamic systems development methods), we have Canvas, and more.

3. The Agile Manifesto

First of all, I would like to read the Agile Manifesto and then the principles behind it. There are many people who support the Manifesto for Agile Software Development. You can read them and their names on the AgileManifesto.org website. We are uncovering better ways of delivering software by doing it and helping others do it. Through this work, we have come to value individuals and interactions with our processes and tools. working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change involves following a plan that says that while there is value in the items on the right, we value the items on the left more. Now, the twelve principles behind that manifesto We follow these principles. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. welcome changing requirements even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter time scale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility and simplicity. The art of maximizing the amount of work not done is essential. The best architecture requirements and designs emerge from self-organizing teams at regular intervals. The team reflects on how it can become more effective than cheaper and adjusts its behavior accordingly. Alright, I hope this video helped you see the core of Agile. Thank you for watching and stay purposeful.

4. How Do We Plan In Agile

How do we plan in Agile? This is the question I want to answer in this lecture. First of all, you should know that the Agile approach is against detailed upfront plans. That is not agile anymore. Upfront plans are typical of waterfall plans. We still do planning in Agile, but we do not have long and complex documents we call plans. Keep that in mind during your exam. What is the big plan for the entire product? This is the product backlog. It is how we believe we should develop the product. Remember, we use the Agile concept of incremental development. The product backlog is transparent and it communicates information. What about the Sprint backlog? This is another Scrum artifact. Well, this is our plan. But for the Sprint, these are the PBIS. When completed, we achieve the sprintgoal, which has business value. On the other hand, in Scrum, we have sprint planning during that event. What do we do? We plan how and what we want to accomplish during the sprint. We have daily scrums. This is for developers only. They plan the work for the next day. As you can see, we plan in Agile, specifically Scrum. But it is important to understand that we act based on one of the scrum pillars. Can you guess which one? Do not worry if you cannot answer right now. It's adaptation. We get feedback, and we adapt. It can be feedback from the customer, for example, or feedback from the end users, the people who pay to use the product. I want to point your attention to something else here. Let's level up a little bit. When we talk about planning, also think about the activities the members of the Scrum team do. Because even though you do not have a return-up-front plan, you can still act in a way that reflects the upfront planning concept. For example, let me give you an example. Imagine you are a product owner and, at the very beginning of the project, you capture a lot of high-level ideas and write them down on a sticky note on a whiteboard, for example. What you are doing is creating a product backlog, which is great. You know precisely the problem you're solving with the product. You've crafted the product's vision. You've come to a point where you are ordering the items in the product backlog. You want to put the items that will add the most value on top. Good job so far. This is the way to go. But you see that these items on top are too big to fit into one Sprint, and they're not very clear. So you and the developers begin by breaking the items down into smaller ones. This is called product backlog refinement. You add descriptions, you add estimations, and you estimate the value these items will deliver. But you've met with the customer a few times and have a lot of ideas in the product backlog; do you think it's a good idea to go through all of these ideas, to all of these items, and refine them to the point where they're ready for development? They are immediately actionable. What do you think? The answer is no. Why? Because in a sense, this is upfront planning. Yes, we took the requirements from the customer, but the fact that an item is in the product backlog does not mean it will be completed. There is a chance we will give up on some of the items or some of the ideas. For example, let's say that a few releases have gone by, we have feedback, and we know that the customer doesn't need some of the items we wrote initially. What do we do in this case? We just don't do these items. They are removed from the product backlog. That's okay. But now imagine if we have spent time breaking these items down, estimating size, estimating value, ordering the items, and so on and so forth. Well, the result here is waste. Let's recap. Agile is against detailed upfront plans in Scrum. We can consider the product backlog to be the big plan for the project. And the Sprint backlog has a smaller plan for Sprint. If the product owner refines items for a few sprints ahead, he or she can reduce waste. For example, two sprints. But that would depend. That would depend on the sprint length. Anything more than that would be considered too much upfront planning. That's it. Thank you for watching. Stay purposeful, and I'll see you in the next one. You.

5. Product Management vs Project Management (Mental Shifts)

I want to start this lecture with the fourth sentence from The Agile Manifesto, which says, "Change is better than following a plan." As you remember from a previous lesson, we do planning in Agile. But what we don't do is make detailed upfront plans for the whole project. We want to be agile. We want to be adaptive. Instead of following a big plan, we want to allow the customer and the end user to provide us with feedback. And based on it, we develop accordingly. Scrum.org is very sensitive about the words "product" and "project." They believe in product management and development, not project management. You also know that in Scrum, we do not have a project manager role. But in traditional project management, we do have project managers, of course. And what do these project managers do? Very briefly, they gather information and create an initial plan with the scope, time, and budget. They ask for resources; they assign tasks. Reporting is a big deal, by the way. Sometimes developers have to explain what they've been working on hour by hour. Gang charts are being used, and so on. Having said that, do not understand that project management is something bad or does not work. No, the problem comes when managers use it incorrectly. Here's what I mean. Most of the time, project managers measure success by adhering sticking to the initial plan as close as possible. The project has met the deadline. It has to be on budget or under budget and within scope. It all sounds good. It sounds logical. But in the book The Professional Product Owner, the authors are asking, "But what about projects that remain on time, on budget, and within scope, yet still do not succeed?" and they give us an example. With Nokia, they produce mobile phones with a high success rate in terms of their projects. Lockheed was the leader in the mobile phone industry. In the mobile phone market, they followed very tight schedules to produce the phones. But they ended up as a department of Microsoft. Nokia didn't make the mental shift from project thinking to product thinking. Again, it's about delivering value through products and not about delivering projects on time, within budget, and within scope. simply because you can be on time and within budget with this code but still not deliver value. And I read something interesting or funny on this topic. It was a blog post on Scrum.org. The operation succeeded as the project, but the patient died. That's the product. This is the result. When project management is used incorrectly, when the focus is on the wrong place, it is not on the end user and their needs. And now the question as product owners who practice product development is: what should we focus on? Consider the following building the right product. Focusing on meeting customers needs and happiness. creating a product vision. balancing priority, risk, value, opportunities, and dependencies to help you build the product in the right way. in the right order. Maximizing revenue and ROI (return on investment) measuring success with business metrics like user adoption and retention and revenue or cost savings generated per feature. Frequently releasing product increments to obtain earlier feedback from the marketplace By using the product mindset and approach, we eliminate waste because we do less task management. We do less people management than we do in the project mindset. In Scrum, you know that we have self-organizing teams. Nobody pushes tasks to the development team. They pull the items from the product backlog. They decompose the items into smaller units we call tasks. And then the developers assign the tasks to themselves, which follow their creativity. It's a task-pulling system instead of a task-pushing system. Okay, time to recap. Responding to change by sticking to a plan Time, budget, and scope are not the best measurements for success. Yet. These metrics can be useful. They are useful, but this is not how you measure success in Scrum. The key to success in Scrum is delivering value through products. So we have happy endusers, Scrum teams, and stakeholders. Useful business metrics for the product owner are user adoption and retention. We want to grow our customers and our customer base, but we also want to keep our customers. We already have revenues or cost savings generated per feature. We strive for higher revenue and lower costs for the organization. In Scrum, project management activities are distributed among all members of the Scrum team. We do not have an equivalent of a PM project manager. Thank you for watching and stay purposeful.

Hide