All Scrum PSM I certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the PSM I Professional Scrum Master I practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Agile & Scrum - Refresh Your Knowledge (PSM I)

16. The Sprint

We've come to the sprint time box, which is the core of Scrum. As the Scrum Guide says, sprints are the heartbeat of scrum, where ideas are turned into value. All the work necessary to achieve the product goal, including sprint planning, daily scrum, sprint review, and sprint retrospective, happens within a sprint. I think that's an important point because I've had students in the past who had a hard time understanding that the sprint itself is a container for all other events.

So the other events are inside the sprint container. Equally important, as one sprint ends, another one begins. This means that we do not have pauses between sprints or, for example, some other events. What about the sprint duration? It can be no longer than one month. However, we should keep in mind that if the project is riskier, we would decide to choose shorter sprints because we want to receive feedback faster. Shorter sprints mean more learning cycles. We should think of sprints as short projects. We have a plan for why, how, and what we want to achieve during the sprint.

We have a sprint goal, and every day we do inspection and adaptation toward that goal. That's why we can think about the sprint's short projects, but all those sprints are going in a clear direction, and that direction is toward the product goal. Also, the sprint team chooses the duration of the sprints, but the idea is to create consistency. Yes, you can discuss the length of the sprint during the Sprint Retrospective events, for example, and you can decide that instead of a one-month sprint, a two-week sprint would be better for your work. for the team.

This is okay, but you do not change the sprint duration while you're in the middle of the sprint. As I said in a previous video, for example, you have two days left until the time box expires. And there are PPI's project backlog items in the sprint backlog that are not done yet. And as a team, you decide to extend the duration of the sprinters' races by two or three more days. No, this is not allowed in Scrum. Some students have also asked me what would happen if the developers completed all the PBIS from the sprint backlog. But the sprint is not over yet. There are a few days left.

The most common thing in this situation is, of course, a collaboration between the product owner and the developers. They move items from the product backlog to the spring backlog. However, this is not a role in which developers can choose to do something else as long as that activity helps the team move closer to the sprint or product goals. In scrum, there are no special sprints such as a hardening sprint, a sprint zero, a technical sprint, or anything else. Whatever you might hear, these might be used. They might be official events in other frameworks or methodologies.

But in Scrum, the purpose of the sprint is to create usable increments that meet the definition of "tongue." These increments are setting stones toward the product goal. I would like to remind you of the agile concepts of iterative and incremental development. Think of one sprint as one iteration. During the sprint, we create an increment that contains all previous increments. And to make it even clearer, think of product versions instead of increments, if you like. Not very often, but there might be a case in which the sprint goal becomes obsolete.

For example, you're developing a website—let's say, software—for trading binary options, which is a financial instrument for the Canadian market. But there is a new regulation in Canada that forbids trading binary options. You're in the middle of the sprint, but there is no point continuing because the sprint goal is no longer valid. This, of course, may or may not apply to the whole sprint project. Maybe you develop trading software for more than one financial instrument—more than just binary options or maybe forex. It doesn't matter anyway.

As you remember, only the product owner has the authority to cancel a spring. Yes, he or she might do it under the influence of the customers, the developers, or the scrum master. But the other roles cannot cancel a screen. Yes, I used the word roles. Roles have been removed from the guide, and now we have a set of accountabilities. but I'm sure you got the point. It's good to know that cancelling an assignment is always bad for the team. Also, it can choose resources.

The entire screen team has to regroup. They have to do another sprint planning event for the next sprint, and so on. All right, now let's do a quick recap. Sprints are the heartbeat of Scrum, where ideas are turned into value. The purpose of a sprint is to create usable increments. We can consider sprints as short projects. The sprints happen one after another.

There are no pauses or other events. The maximum duration of the sprint is one month. Typically, when the project is riskier, shorter sprints are preferred, so we can generate more learning cycles. The sprint can be cancelled when the sprint goal becomes obsolete. Sprint cancellations are always bad for the team. It requires regrouping of the team and a sprint planning event, and as a result, resources are lost during the sprint quality. Goals do not decrease, and goals might be renegotiated as more is learned. The Scrum team does not make changes that would endanger the sprint goal. Thank you for watching. I will see you in the next video. Stay purposeful.

17. The Sprint Planning Event

It is time to talk about the first Sprint event, Sprint planning. This event is about planning. The work that needs to be performed during the sprints simply says that we plan what we want to build. The entire script team collaborates during the event. The product owner ensures that attendees are prepared to discuss the most important product backlog items and how they map to the product goal. By the way, if you look in the past, you'd notice that the product owner was always deeply involved in Sprint planning. And now, with the introduction of the product goal as a commitment, it is becoming more and more obvious. Sprint planning addresses three questions. The first one is: why is this Sprint deal valuable? We didn't have this question in previous versions of the Scrum guide, and I'm very happy that it has been added because, regardless of the framework methodology or many drawn styles we have, we should always start with the question why? Why is this important? Why is this valuable? And here the product owner explains to the team why he or she brings up a business objective. At this time, this would be the most valuable thing to do. Then the entire Scrum team, the entire Scrum team, defies the Sprint Goal, a critical concept here. The second question is, "What can be done this sprint?" This is the part where the developers select items from the top of the product backlog. Basically, they collaborate with the product owner, and they're making a forecast of the items they can complete. It is not okay if the developer selects, say, five items and the product owner says, "No, no, that's not enough; let's add two more." This is not okay. Another interesting thing happens. To create more or less an accurate forecast, the developers have to have a good understanding of the PiS, and that often requires what's called "product backlog refinement." Product backlog refinement can happen at anytime, but also during Sprint planning. The wholespring team does it, and the result is PVs that are refined and ready for development. Now, what else should the developers know in order to create or give more accurate forecasts? And, of course, increase their confidence in that forecast? The developers' past performance, their upcoming capacity, and their definition of done This is what they consider and account for when making a forecast. Why is that their definition of them? You might be asking already. Because, as I said, think about the definition of them as a checklist with bullet points, the developers are required to conform to the definition of them.

So basically, that checklist helps the developers determine how much work would go into each selected PPI. This is how it helps with the forecast for the spring. Let's go to the next question. How will the chosen work get done? Since we've selected the items, now it's time to think about how to turn them into an increment that meets their definition of them. The developers plan the work. They plan what has to be done. And here, the scroll guide is quite clear. No one tells the developers how to turn PBIS into increments of value. That means the developers are the professionals who choose the practises they want to use to give these PBIs life, so to speak. And I can be more specific by using an example from the IT industry.

For example, the developers might want to use test-driven development, pair programming, and so on. These are practises in the software world, right? They come from extreme programming. By the way, if we are talking about another interesting industry such as healthcare, again, I would assume the developers would be able to choose among different practises in order to get the job done. The important thing to remember here is that they—the developers—decide who does the work. We have now completed the spring backlog by the end of spring planning. We will talk about it as well. I have a dedicated lecture for it. But for now, remember that the spring backlog consists of the spring goal, the PBIS, and the plan for delivering these PPIs. So those three elements are: a goal, a chosen PBI, and a plan.

As for the length of the event, springPlanning is timeboxed to a maximum of 8 hours for a OneNote sprint time for a recap. During sprint planning, the product owner ensures that attendees are prepared to discuss the most important PBIs and how they map to the protocol. During sprint planning, we answer three important questions: Why is this sprint valuable? What can be done? This Sprint? How will the chosen work be done? The entire script team attends and collaborates on creating the sprint goal. The developers choose how many PBIS to include in the Sprint Backlog.

The developers decide on the practises they would use to turn product backlog items into usable products. The more the developers know about their past performance, upcoming capacity, and definition, the more accurate forecasts they will be able to make. The spring backlog is created during spring planning and is a combination of three things: the spring goal, the selected PBIS, and a plan to deliver them. The Sprint team may invite other people to attend Spring Planning to provide advice. Thank you for watching. I'll see you in the next video. Stay Purposeful.

18. Daily Scrum

We've come to the daily scrum event. The general purpose of this event is to inspect progress towards the spring goal and adapt the spring backlog if needed.

So it is about inspection and adaptation. During the daily scrum, the developers plan their work for the next day. This event is for the developers, but the product owner and the scrum master can attend as well. Also, the guy says that if the product owner and the scrum master are actively working on items in the spring backlog, they participate as developers. This helps us remember that one person can act as both a product owner and a developer, or as a Scrum Master and a developer. There's no problem with that. But for your exam, remember that DailyScrum is mandatory for the developers. Also, they are responsible for conducting the event. On the other hand, the Scrum Master ensures the daily scrum as well as the other events, of course, take place, enter, are positive, productive, and are kept within the time box. So let me say that again, because the difference might not be that significant.

That obvious. The developers are responsible for conducting the event, but the scum master ensures that the developers have the event. The event takes place. Here is something tricky. The duration of the scrum events changes according to the duration of the sprint. But this is not the case with the daily scrum. The daily scrum is always 15 minutes, no matter the length of the sprint or the number of developers. Some of my students have asked me in the past what would happen if the developers were ready for ten minutes. Do they have to wait five more minutes before they go back to work? and the answer is no. If the developers are ready in ten minutes, or twelve minutes, or 13 minutes, they go back to work. We do not break any rules. Here's another characteristic. It is held at the same time and place to reduce complexity. This is a daily effect. Imagine what would happen if every data developer had to discuss where, when, and what time the daily scrum should be. This would result in a lot of waste, which we do not want. To put it simply, we want the same time on every working day of the sprint.

Now, as for the structure of the meeting, scrum doesn't give us a structure. With the most recent update in the past, yes, we had to answer the three famous questions: What did they do yesterday? What will they do today? Do I see any impediments? And I'm paraphrasing here, of course. In the Scrum Guide from 2017, these questions became optional. This was just one example of the Dave Scrum structure. It was not a problem to have an open discussion instead of asking questions. And now, with the latest update of the Scrum Guide, these questions have been completely removed. But here is what we have to remember: Developers can choose whatever structure and techniques they want as long as the event focuses on progress toward the spring goal and produces an actionable plan for the next day of work. Now I want to focus your attention on this daily Scrum improves communication, identifies obstacles, promotes quick decisionmaking, and consequently eliminates the need for other meetings.

Can the developers discuss and adjust their plans for the sprint outside of that event? Outside the exercise, The answer is yes. No problem. The guy says The developers often meet throughout the day for more detailed discussions about adapting and replanning the rest of the spring's work. Also, the people behind Scrum do not like when we change Scrum terminology. So the name of the event is "Daily Scrum" and not "Daily Standup." In other frameworks, daily standup is an official event. I believe in a safe scale title framework. But for your exam, Daily Standup is not an event in Chrome. It's time to recap the daily scrum. The purpose of Daily Scrum is to inspect progress towards the spring goal and adapt the spring backlog if needed. Daviscrump is a mandatory event for all developers on the Scrum team. The Scrum Master ensures that Scrum takes place, but the developers are responsible for conducting the event.

The developers intend to work the following day during Daviscom. The scrum master and the product owner are allowed to attend Daviscom. DavisCom is always 15 minutes, regardless of sprint length or number of developers. David Scrum is held at the same time and place every working day of the sprint. To reduce complexity and eliminate waste, developers choose the structure of the data for the Scrum event. The focus of the event should be progress toward the spring goal and an actionable plan for the next day. Daviscrofts improve communication, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The developers are allowed to adjust their plan to achieve the spring goal outside Davis Cross as well. Often they meet throughout the day for more detailed discussions. Thank you for watching. I'll see you in the next video. Stay purposeful.

19. The Sprint Review Event

Welcome to the Sprint Review event. This is the second-to-last event inside the Sprint container. The last one is Sprint's retrospective. What is the main purpose of this event, and who attends, as you already know? The main purpose is to inspect. It's about inspection and adaptation. But the question is: what do we inspect? Well, this is the outcome of the sprint.

This is what the developers built during the Sprint. As for adaptation, it refers to the direction we are going. The scrum team and the stakeholders want to go toward the product goal. So the Sprint review will review the increment in the context of both the Sprint goal and the product goal. The scrum guide says the scrum team presents the results of their work to key stakeholders and progress toward the product goal is discussed. And this, by the way, answers the question, "Who attends this event?" The answer is the whole-scrum team and key stakeholders. In the previous version of the guide, the general purpose of this event was to get feedback from the customers and from the stakeholders.

This hasn't changed. It is just stated in different words. We still expect the input of the stakeholders. We still expect that feedback to give us important information, so we as a scrum team can use it to adapt. During the event, the scrum team and stakeholders review what was accomplished in the sprint and what has changed in their environment. Based on this information, attendees decided together what to do next. The product backlog may be adjusted to meet new opportunities. The Sprint review is a working session, and the script team should avoid limiting it to a presentation. With that being said, we should remember that the sprint review is not just a demo of the increment. It is not just a presentation but rather a working session. The feedback and the exchange of information are what matter. And I know I'm repeating myself, but I really want you to get to this point. The scrum team then presents only items, only PDFs that are 100% complete by their definition.

We do not present nearly finished items because, as you might expect, presenting incomplete items may result in incorrect feedback. and this would negatively affect the adaptation part. And this is the same as when we calculate the velocity of the developers. We only include PDFs from previous springs that have been completed completely. Again, scrum is very sensitive about the word "done." Now, what would happen if the customer continuously skipped the Sprint review event? By the way, think of customers as stakeholders. We've completed several sprints and done a lot of items, but the customer didn't see a demo or a presentation of the increment. The customer didn't provide us with any feedback. And if that happened, there was a chance that there would be a misalignment between the expectations of the customer and the expectations of the scrum team. more specifically, the expectations of how the product should look and function. And this is not good. The customer wouldn't be happy. the scrum team as well. This is the price. This is the price we pay for delayed feedback. We want fast, opposite feedback so we can adapt and move toward customer expectations and the product goal. In scrum, we do not fear changes. We welcome feedback.

But if changes are delayed, then we have a problem. In a business book, I read an interesting phrase: if we decide to make a change during planning, it might cost us $1. But if we decide to make the same change in three months, it might cost us $10,000. Sprint Review is a four-hour event for a one-month sprint. Let's do a recap. The purpose of the Sprint Review event is to inspect the outcome of the sprint and determine future adaptations. The scrum team presents the results of their work to key stakeholders and progresses to where the product goal is discussed. Attendees of the Sprint Review event are the scrum team and key stakeholders. Sprint Review is more than just a summary of the increment. The scrum team presents all the items that have been completed 100% according to their definition of them. If a customer routinely skips this event, the expectations of the scrum team and the customer would become misaligned, and both parties would not be happy. The product backlog may be adjusted to make room for new opportunities. The Sprint Review is a four-hour event for a one-month sprint. Thank you for watching. I will see you in the next video. Stay purposeful.

20. The Sprint Retrospective Event

The Sprint Retrospective is the Scrum team's final event. It happens after the sprint review and before the next sprint planning event. The main purpose of this event is to plan ways to increase quality and effectiveness. The Sprint Retrospective event is designed for inspection and adaptation. But this time we do not inspect the increments—the work the developers did during the sprint.

Now we inspect the processes the team used to build the increment. And more specifically, the Scrum team inspects how the last sprint went with regards to individuals, interactions, processes, tools, and their definitions of them. With that being said, I want to focus your attention on the fact that this event is about the context and not the content. What do I mean by that? Let me give you a few examples. We do not discuss PBIS, but we may discuss ways to write clear descriptions of the system or maybe discuss tools to help us communicate with members of the team who work remotely. Or we might discuss the importance of communication among the members of the Scrum team. Do you recall the product owner explaining PBIS to developers?

And if he or she doesn't take the time to talk to the developers, this would negatively affect speed and effectiveness. Or we might discuss the length of the sprint, the structure of the daily scrum, adjusting the definition of dumb, and so on. As you see, all these topics lead to the word "effectiveness." There is always room for improvement. The Scrum team identifies the most helpful changes to improve effectiveness. The most impactful improvements should be addressed as soon as possible. They may even be added to the sprint backpack for the next sprint. In the Scrum guide from 2017, we had the rule that at least one high-priority process improvement must be included in every spring backlog. And the update from 2020 states that these improvements may even be added to the sprint backlog for the next sprint. Yes, the guide is not that prescriptive anymore. So now we may or may not add these improvements to the Sprint backlog. But the fact remains that the scrum team must address these as soon as possible.

As with all other Scrum events, the Sprint Retrospective is mandatory. We are not allowed to skip it. The time box for the Sprint Retrospective event is 3 hours, and as usual, it is shorter for shorter sprints. The main purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum team inspects how the last sprint went with regards to individuals, interactions, processes, tools, and their definition of dumb. It is a three-hour event for a one-month sprint. It is an opportunity to inspect and adapt the process the Scrum team has been using to build the increments. The whole Scrum team attends the event during the Sprint Retrospective. We talk about the context and not the content. For example, tools to help us communicate with members of the team who work remotely; the importance of communication between the team members; the length of the sprint; the structure of the daily scrum; the definition of them; and so on. Thank you for watching. I'll see you in the next video. Stay purposeful.

Scrum PSM I practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass PSM I Professional Scrum Master I certification exam dumps & practice test questions and answers are to help students.