Pass Scrum PSM I Exam in First Attempt Easily

Introduction

1. Legal Disclaimer

Hi there, and thank you for registering in this course. Before we get started, there are a couple of things I want to make clear right from the beginning. First of all, in order to successfully pass the certification, you need to invest some time in studying the Scrum Guide. And trust me, there is no way around it. Now, I know that a Scrum Guide is rather dry and can be, at times, confusing. I have broken it down in small sections so that it's easier for you to read and digest. I just wanted to point out that you need to read and understand the ins and outs of the Scrum Guide. Just watching the video lectures might not be enough to have the understanding needed. Generally, you need to go over the course once to get an overview of Scrum and then come back and watch some of the lectures again. Print the Scrum Guide and underline any parts you consider relevant. Additionally, I recommend that you create your own summary of the Scrum Guide so that you can easily review the most important aspects when needed. You can view the Scrum Guide as a piece of legislation. While not particularly long, every word in each sentence has been individually selected, and it is important to get the meaning. Almost nothing is formulated by chance, so don't underestimate it just by the number of pages and give it your full and undivided attention. During the course, you will find quizzes and assignments. They are there to evaluate what you have learned and to make sure you stay on track while you are learning. Some of the questions you will encounter are trick questions, so make sure you take a moment, read the questions, review all the answers, and only then make your selection. This is done on purpose, and believe me, it is not to irritate you, but to prepare you for the real-world exam. Please understand that this course does not deal with all aspects of Scrum. While I have tried to make the ScrumGuide more understandable and to give you real-world examples, the focus of this course is still on the contents of the Scrum Guide and the Professional Scrum Master I certification. Nevertheless, some of the lectures will include additional resources, which I would recommend looking into to improve your understanding of Agile and Scrum. Enjoy the course, and anytime you have a question, feel free to get in touch with me. I'll be more than happy to help and point you in the right direction.

2. Introduction

Jack and Mary Organic Farm has a tradition of over 50 years on the market. It specialises in the production of gems and jewelry, and as often happens with traditional companies, they have not really managed to keep up with the latest technological changes. Until now, they only sold the product to wholesalers or at the farmers market. But the customers ask time and again if they could order online. Now they have brought on board a team of six professionals to create a new ecommerce platform for the company so that they can sell their products over the internet. So let's meet them. Holly is experienced with Scrum and has proposed to give Scrum a try for this project. All others, including the company CEO, are excited to learn what Scrum is and how they can all benefit. Jessica has a good understanding of ecommerce and has been involved in similar projects in the past. Aki, Michelle, Tom, and Max bring a mixed set of skills on design, programming, and testing, all crucial to the building of the e-commerce site. The company CEO and board of directors are the ones who wanted to have the e-commerce solution, and they all know that the future of this company depends on the outcome of this project. So they are the stakeholders in this project. Together they will learn what Ross Crumb is and how it can apply to real-world problems.

3. Pre-requisites for taking the exam

Scrum is a framework for dealing with complex work, such as new product development. Nowadays, with constantly changing market conditions and technology improvements creating a high level of uncertainty, it is possible to predict from the beginning how products should be developed. So in these conditions, working with timeboxes and quick adaptation is mandatory to ensure that a project does not fail. Scrum is a framework that imposes time boxes and feedback loops and tries to deal with uncertainty. What Scrum does is take a bit of all the steps required to develop a product, such as requirements analysis, design, development, and testing, and put them into a fixed-length iteration called a Sprint. So the Sprint combines all aspects of the work. Right from the first sprint, a Scrum team will try to create a working, tested, and potentially shippable product increment, even if it's not released to the end user yet. After each print, they demonstrate what they have accomplished and discuss what should be done next. Customers often need to see the wrong product before they can say what they really want. The short iterations allow for constant feedback and improvement, so that the probability of creating the right product is substantially increased. In order to accomplish this, the team need to have all the skills needed to do business requirements, analyzes, design, development, testing and whatever else is needed, so that by end of a Sprint, a potentially Super Bowl product is created. All that. In a cross-functional self-organizing team, Scrum defines three roles: the product owner, the development team, and the Scrum master. Everyone on the Scrum team. The product owner will create a list of features called the product backlog and organize them by importance, with the more important items being at the top. During sprint planning, the team will select a list of items from the top of the product backlog and try to turn them into a potentially shippable product increment. The team has a fixed time frame to complete the work, and they meet in a daily scrum to synchronize, identify problems, and keep the work moving forward. During the entire process, the scrum master keeps the team focused on the sprint goal. At the end of the sprint, the product increment should be potentially shippable, and the Scrum team, together with stakeholders, conducts a review of the product in the sprint, followed by a retrospective of the process. And then the Scrum team starts from the beginning with the next sprint planning and the cycle repeats.

Hide

Scrum Events

1. What are the Scrum Events

Scrum uses prescribe events or call them meetings if you prefer, to create a routine and to reduce the need for other meetings that are not defined in Scrum. At the heart of Scrum is a sprint which acts as a container center for all events. All events within Scrum have a maximum duration and are the four time boxes in Scrum. All events are designed tenable transparency and inspection. Sprint planning where the work to be performed in the sprint is planned. The daily Scrum which is held every day of the sprint, sprint Review which is held at the end of the sprint to review the increment and sprinter which is an opportunity to improve, are all events which are a former opportunity to inspect and adapt. In the following lectures we'll take a closer look at each event.

2. Product Backlog

In Scrum, the product backlog is an artefact designed to provide transparency and opportunities for inspection and adaptation. The product backlog is made up of an ordered list of everything that is needed in the product. It is a list of requirements, which can be new features or improvements, fixes, or any other changes that need to be done on the product. As long as the product exists, so will its backlog. If multiple teams work on the same product, only one product backlog should be used. The items in the product backlog are referred to product backlog items," which have a few characteristics such as description, order, estimate, and value. Product backlog items should also include a description that will help test if the work performed is complete. The sole person responsible for the product backlog is the product owner. This means that the product owner is responsible for the content and the ordering of the product backlog. So how exactly is the product backlog created and managed? The product owner will usually try to understand the business requirements by keeping close contact with the stakeholders. The product owner will add features or ideas to the product backlog as he or she deems relevant for the product. Managing the product backlog is an ongoing process, and while the product owner is responsible for the backlog, he or she can add orders or move backlog items at any time he or she sees fit. It does need to closely work with the development team on that. During the product backlog refinement meeting, the product owner and the development team work on adding details, estimates, and order to the product backlog. What is also important to remember is that the development team is responsible for all estimates and has the final say on that. This meeting is not part of the prescribed Scrum events. The Scrum team decides how and when refinement is done. Nevertheless, the product backlog refinement still has a time box in the sense that it should not occupy more than 10% of the capacity of the development team. One definitive characteristic of the product backlog is that it is never complete and is constantly changing. The product backlog grows with the product itself and changes based on business requirements, market conditions, or any other relevant factors. Product backlog items that are positioned higher in the product backlog are more important as they provide a much greater value and are usually clearer and more detailed than the items in the lower part of the product backlog. Generally, it is not worth investing a lot of time into adding a lot of details to backlog items way down in the product backlog. It is okay for those items to have a lower degree of detail and clarity, but items right at the top of the backlog are refined so that they can be done within the Sprint time box. The product backlog items that can be done in the next sprint are deemed ready for selection by the development team. This usually means not only that the items are small enough to fit within a sprint, but that they are detailed enough and immediately actionable. While this is not part of the Scrum Guide, some teams choose to create a definition of "ready" for the product backlog items that are about to be selected for the next print. In other words, a product backlog item is ready when the team agrees it can be done. You.

3. Product Backlog in Practice (Optional)

One of the first things our product owner Jessica needs to do is get started creating the product backlog before the first sprint can begin. Remember, the product owner is responsible for the product backlog. Before she talks to the stakeholders, she will understand what is needed from a business point of view, but she will also talk to the development team. Of course, Jessica already knows that Jack and Mary Organic Farm want an online shop, but how everything should work still needs to be figured out on the way. So she starts creating a list of features, trying to keep them as small as possible. The first product backlog item would be to create a home page. The next item would be to create a page to display one product, build an order form to display multiple products, add to-cart functionality, accept credit card payment, and so on. So any other features or ideas regarding the product will land in the product backlog. Currently, these items don't really mean a lot. So next, the product owner will work together with a development team to add more details to the a Remember, a product backlog item should have a description, order, estimate value, and test description. But what exactly will this look like? Our product backlog item is described as being totally left up to the Scrum team. The Scrum Guide does not offer any templates or make any suggestions regarding the format itself. In practice, it is quite common for Scrum teams to use user stories. It is actually so common that product backlog items are simply referred to as stories. Alia thinks it's a good idea to use user stories, and the team agrees to give them a try. But what are user stories anyway? User stories are rather short descriptions of the future explained from the perspective of the person who desires the feature, usually a user or a customer of the product. The template for a user story looks more or less like this. So this is how the first product backlog item can be formulated as a user story. Create a home page. As a customer interested in Jack and Mary Organic Farm, I want to open a browser and view some basic information about the company so that I can make contact in case I have some questions. Now let's see the test description, sometimes also called an acceptance criteria test description. I should see the logo of Jack and Berry Organic Farm. I should see the postal address, the email address, and the phone number. So in this case, the product backlog item is written as a user story. But it doesn't mean that every item in the product backlog needs to take the form of a user story. Remember that a Scrum guide makes no references to user stories, and they are definitely not mandatory in Scrum. Let's go ahead and see what another story looks like. Display one product. As a customer interested in products from Jack and Mary Organic Farm, I want to open a browser and find some basic information about the Strawberry Jam product so that I am better informed about the ingredients and available sizes. The strawberry jam is the best-selling product at Jack and Mary Organic Farm, and a lot of customers ask questions about the product, so for this story, the product description will be the following the home page will include a button called Our Product. When clicked, it should open a new page. The Product Page The product page should display one or more images of the product, include a short description, and include a FAQ section with questions and answers. So Jessica has written a few user stories, and they are done by now. But our product backlog is by no means complete, nor will it ever be. More product backlog items will be created and refined during the following sprint as more is learned about a product. While the product owner is responsible for the content and ordering of the product backlog, it does not mean that the development team cannot write product backlog items or user stories as well and discuss them with the product owner. However, the product owner still remains accountable.

4. Product Backlog Refinement in Practice (Optional)

Now the stories have a description, a test description, a value, and an order as they are the first and second items in the backlog. As you notice, the story is not complete yet. The next step would be to take this product backlog item written as a user story and discuss it with the team to clarify the details, add it to the order, and get an estimate. This collaboration between Jessica, the product owner, and the development team happens during the product backlog refinement meeting. This time Jessica will take the first story from the product backlog and show it to the team right away. Tom has a question. What if the phone number changes? Do we need an admin panel to be able to change that? "Actually, that would be nice to have," replies Jessica. "Maybe you should update the story to reflect this new information," says Ali. "Good idea!" replies Jessica. Any other questions? Ask the product owner. If not, can you give me an estimate for this backlog item? "For me, it is still unclear what an estimate is and how to do it," says Michelle. Ali agrees with Michelle. Indeed, we haven't discussed yet how we'll estimate product backlog items. Let me explain a bit. An estimate in the usual sense is the best guess at the effort necessary to carry out a given task. For example, one product backlog item But as I said, it is a best guess, not a commitment. There's always some uncertainty, and that is fine. So it means we should say how long it will take us in days? Ask Michelle. Not really, explains Ali. According to Ally, scrum differs from other traditional project management techniques in many ways. Compared to climbing a mountain, which is just a small hill, it will be kind of easy. If you want to climb the Himalayas, it will be more complex. So when building functionality, you want to know the size first. Is it just a small hill or a mountain? Does that make sense? "Kind of," but I'm still unsure how to proceed." Ali continues. Let me put this on a scale. Imagine that zero is a walk in the park, almost no effort at all, and 100 is climbing the Himalayas. This would be the start and end of the scale. Could you now pick a number between 1 and what you think represents the effort of building this functionality? Asked Ali. I guess so. Replies Michelle then each other. Write your number on a post-it note and keep it secret for a moment. Let's now look at the numbers 714 1930.Now let's imagine that you can only pick one of the following numbers: zero, 123-581-3204, and 100. This is an estimation technique called planning poker. Now the interval between the numbers is much larger and forces you to go up or down. Just try it. Now we only have 813, and 20 looks much better than what we started with, explains the Scrum Master. Let's now discuss your estimates and reach a consensus. Occur, you had an aid. What were your reasons? "Well, this is a very simple page with a logo and some text, so not a big deal," explained Akee. Have you considered that we need to have an admin panel to edit that information? Asks Max. I'm afraid I've only estimated the design work. Let's try again. Please recommend a Scrum Master for 2020. "It seems that we agree," concludes the Scrum Master. Is there anything I can change regarding the product backlog item in order to reduce the complexity? Ask Jessica. I guess the admin panel is something that is driving complexity up. Okay, I am more than happy to leave that out, at least for the moment. Could you estimate the product backlog item again, this time without the admin panel? Ask the product owner. Eight. Eight. Great. Thank you all. Says Jessica. I'll write down your estimation.

5. Sprint Planning

The Sprint planning meeting is time-boxed to a maximum of 8 hours for a one-month Sprint. Of course, for small sprints, it should be proportionally smaller. This event usually happens after the conclusion of the previous sprint. During the event, the product owner and the development team will agree on a Sprint goal and discuss which items from the product backlog will be added to the Sprint backlog. Let's take a minute to understand what the difference is between the product backlog and the Sprint backlog. The product backlog is a wish list of features the product should or could have. So, basically, everything that could be done is referred to as backlog items in the list. The Sprint backlog contains the product backlog items that will be done in the current Sprint and a plan for how to deliver the functionality. So the work that needs to be done will be decided during the Sprint planning meeting. The first step of this meeting is to understand what can be done in the sprint. The product owner presents the objective that the Sprint should achieve and the product backlog items that, if completed in the Sprint, would achieve the Sprint goal. The development team will work to forecast what can be done in the Sprint. This doesn't mean that the product owner decides the amount of work the development team will do. The number of product backlog items selected is solely up to the development team. In order to make the above mentioned forecast, the Scrum team has a few details they need to take into account, which are the latest product increment, the projected capacity of the development team, and the past performance of the development team. Once the Sprint call has been defined and the product backlog items for the Sprint have been selected, the development team discusses how the functionality will be built into a product increment. In the event that the estimated work is too much or too little, it may renegotiate the selected product backlog items with the product owner when needed. The development team may also invite people outside of the Scrum team to attend and to provide technical or domain advice. By the end of this meeting, the work plan for the first day of the Sprint has been broken down into units of one day or less. Because work emerges during the Sprint, this meeting cannot identify all the work that needs to be done in advance. It is just a plan with enough details that the development work can start. The development team should be able to explain to the product owner and scrum master how they plan to accomplish a sprint call and create a forecasted increment.

6. The Sprint

A Sprint has a time box of one month or less in which a potentially shippable product increment is created. If the duration of the sprint is too long, the complexity and risk may increase. With these relatively short horizons, it is also easier to plan what is being built and to get early feedback. Sprints contain all the prescribed scrum events, a flexible plan on how to build a product increment, and of course, the development work needed. Sprints are used to accomplish something, even if it is very small. Each Sprint has a Sprint Call, which is an objective that will be met within the Sprint timebox and which helps the development team better understand why it is building the increment. During the Sprint, no changes should be made that would endanger the Sprint goal. It is also important that the quality standards do not decrease, especially if the time off is about to expire. As the product increment is built, new things are learned. When necessary, the scope of the Sprint may be clarified and renegotiated between the development team and the product owner. A newer sprint starts immediately after the previous sprint has ended. There is no gap between Sprints, and nothing happens between the Sprints.

7. Cancelling a Sprint

Cancelling a sprint. Canceling a sprint before the time box expires is a very, very rare occurrence. I actually never encountered this, but you need to be aware of this possibility as well. Sprint can be cancelled if the Sprint call becomes obsolete, if there are some major and sudden changes on the market, or if the company decides to change directions. But again, because sprints are usually very short, this is really an extraordinary event and very, very uncommon. Nevertheless, only the product owner has the authority to cancel the Sprint. It may do so if advised by the stakeholders, the development team, or the Scrum Master. but only the product owner can take this decision. If a Sprint is canceled, product backlog items that are completed will be reviewed. Incomplete product backlog items will be re-estimated and put back into the product backlog.

8. Daily Scrum

The Daily Scrum is a time box event held at the same time and place each day to reduce complexity. The Daily Scrum is held every day during the sprintand it is an event intended for the development teamand I'm stressing this a bit because it is important. During this event, the development team plans what work will be performed in the next 24 hours. The Daily Scrum is a key-inspect and adapt meeting in Scrum. The Daily Scrum helps the development team inspect progress toward completing the work in the sprint backlog and reaching the sprint goal. The structure of the meeting is set by the development team and can involve questions or can be more discussion-based. While it's totally up to the development team how the meeting is conducted, the Scrum Guide gives an example of questions that could be used. What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal?

Do I see any impediment that prevents me or the development team from meeting the sprint goal? The interactions that the development team has should improve communication, identify impediments, and promote quick decision-making. Regardless of the size of the team, the Daily Scrum is a 50-minute time box event when needed. The development team will meet immediately after the Daily Scrum to further discuss and decide on how the rest of the sprint work will be completed during this meeting. The Scrum Master's role is to ensure that the development team meets and that it adheres to the time constraints. While this is an internal meeting, the development team could allow for others to be present. The Scrum Master ensures that they do not disturb the meeting. This is a meeting for the development team and not for reporting progress to the product owner or the stakeholders. Overall, Daily Scrum improves their communication and the need for additional meetings within the team. Identify impediments and help the team make quick decisions.

9. Sprint Review

By the end of the Sprint, the development team should have delivered a potentially shippable product increment. So when exactly does the Sprint review take place? The Sprint Review is held at the end of the Sprint in order to inspect the product increment and adapt to the product backlog if needed. The product owner owns this meeting and will invite key stakeholders to this event. Also taking part are the development team and the Scrum Master. The ScramMaster role is to facilitate this meeting and make sure it is held within the time box. This is at most a four-hour meeting for one-month month Sprints. For shorter sprints, the event is usually shorter. The Sprint Review is an informal meeting, not a formal status meeting. The demonstration of the increment is done in order to obtain feedback and encourage collaboration on what needs to be done next. So how exactly does this meeting work? A typical agenda for this meeting is something like the product owner explaining which product backlog items have been done and what has not been done. As the product owner is responsible for maximising the value of the product, it should explain how the product backlog items help achieve that. During this meeting, the development team makes a live demonstration of the product backlog items that have been done, which is actually the highlight of this meeting. It is particularly valuable to have stakeholders try out a product with their own hands in order to get a better understanding of what has been built. The development team also discusses what went well, which problems they encountered, and how they have solved them next. The product owner discusses the product backlog and explains when a next release might be available. Based on the progress to date, the entire group collaborates on what to do next and discusses changes in the marketplace. So in other words, this step involves strategic planning for what is important to do next. This meeting is not only a good opportunity for the Scrum team to gather feedback, but also for the stakeholders to ask questions or to suggest changes or new features to the product owner. Often, this meeting can result in a revised product backlog based on feedback or new opportunities on the market. And we previously said that during this meeting, only done product backlog items are being reviewed. So you're probably wondering what happens with product backlog items that have not been done yet or that are not fully done. For example, some functionality has not been built, or more testing is needed and that is not completed yet. So, first of all, they will not be demonstrated during this meeting, and they should not be part of the product increment. They will be put back in the product backlog. So, in a nutshell, this is a sprint review meeting.

10. Sprint Retrospective

The Sprint Retrospective is the very last event in the sprint, right after the Sprint Review but prior to the next Sprint Planning. While in the Sprint Review meeting, the focus was on inspecting and adapting. The product goal of the Sprint Retrospective is to inspect and adapt the process. Only teams that reflect on what has happened and identify what can be improved in the future can be more effective by adapting the development process and making it more enjoyable. The Sprint perspective is an internal Scrum team event where no external parties are involved. Having stakeholders or management involved in this meeting would most likely inhibit the team from openly discussing the problems in C and would reduce the effectiveness of the meeting. Any discussion with external parties regarding the improvement of the process should be done outside of this event.

The Scrum Master acts as a facilitator for this meeting, makes sure that everybody understands the purpose and ensures that the meeting is positive and productive, and coaches the team to keep the event within the time box. The Sprint Retrospective is, as implied, a time box event. For a one-month sprint, the maximum duration is 3 hours. For shorter sprints, the distance should be proportionally shorter for this event. The Scrum guide does not make any explicit suggestions on how the meeting should be structured or conducted; it just points out the purpose and the desired outcome of the meeting. So the purpose is to look into how the last sprint went with regard to people, relationships, processes, and tools. Typically, the team will gather reflections on what went well and what can be improved in this step.

The team will discuss the findings, attempt to understand different perspectives, and try to identify the major items that went well and potential improvements. Once the most important improvements are identified, it is time to create a plan for implementing those improvements in the next sprint. In order to improve the quality of the work they deliver, the team may want to improve the definition of done during the retrospective.

Dan refers to a common understanding of what it means for work to be complete. As multiple parties are involved in the process, it is necessary to define what done means so that it is transparent for everybody. The definition of "done" is used by Scrumptious to assess when work is complete on the product increment. Usually the definition of "don" will include some quality criteria as well. So the definition of done can be changed during this meeting by the team to include new conventions, standards, and guidelines as seen appropriate by the team or to make existing ones stricter. While issues and potential improvements can be identified by the team anytime during a sprint, the sprint retrospective provides a formal opportunity dedicated to inspection and adaptation.

Hide