21. Recap Of Scrum Events
Let’s start with the sprint. Sprints are the heartbeat of scrum, where ideas are turned into value. The purpose of the 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 risky, shorter sprints are preferred so we can generate more learning cycles. The sprint can be cancelled when the sprint goal becomes obsolete. A Sprint cancellation is bad for the team. It requires a regrouping of the team and a new sprintplanning event, and as a result, resources are lost. During the sprint, quality goals do not decrease. The scope might be renegotiated as more is learned.
The sprint team does not make changes that would endanger the sprint goal. Planning the next sprint During sprint planning, the product owner ensures that attendees are prepared to discuss the most important PVIs and how they map to the product goal. During sprint planning, we answer three important questions. Why is Sprint valuable? What can be done with Sprint? How will the chosen work get done? The entire scrum team attends and collaborates on creating the sprint goal. The developers decide how many PBIS to select for the sprint backlog. The developers decide on the practises they would use to turn PBIS into a usable increment. The more the developers know about their past performance, upcoming capacity, and definition, the more accurate forecasts they will be able to do. The Sprint Backlog is created during sprint planning and is a combination of three things: the sprint goal, the selected PBI, and a plan to deliver them. The scrum team may invite other people to attend sprint planning to provide advice.
Sprint planning is 8 hours for a one-month sprint. Daily Scrum The purpose of daily scrum is to inspect progress towards the sprint goal and adapt the sprint backlog if needed. The daily scrum is a mandatory event for all developers on the scrum team. The Scrum Master ensures that this takes place, but the developers are responsible for conducting the event. During the daily scrum, the developers plan their work for the next day. The Scrum Master and product owner are allowed to attend daily scrums. The daily scrum is always 15 minutes, regardless of the length of the sprint and the number of developers. The daily scrum is held at the same time and place every working day of the sprint. Developers choose the structure of the daily scrum event to reduce complexity and waste.
The focus of the event should be progress towards the sprint goal and an actionable plan for the next day. Daily scrums improve communications, 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 sprint goal outside of the daily scrum as well. Often they meet throughout the day for more detailed discussions. Sprint Review: 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 progress toward 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 only items that have been done 100% according to their definition of them.
If a customer routine eludes 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 also be adjusted to meet new opportunities. The Sprint Review is a four-hour event for a one-month sprint, followed by the Sprint Retrospective. The main purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The scrum team inspects how the last print went with regards to individuals, interactions, processes, tools, and their definition of done. 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, not the content. For example, tools to help us communicate with members of the team who work remotely, the importance of communication between team members, the length of the sprint, the structure of the daily scrum, or their definitions and so on. There you have it, a recap of the most important points regarding the scrum events. Make sure you download the PDF file and print it out so you can read the points yourself at your own pace. Thank you for watching. I am proud of the progress you are making, and I’ll see you in the next video. Stay Purposeful.
22. Intro – Artifacts & Commitments
As for the Scrum artifacts, they haven’t changed. You know them by now. But in the next videos, we will dig deeper into their characteristics. For now, it is good to remember that each artefact is designed to maximise the transparency of key information. Why is this important? Because we need transparency to do inspection and adaptation, We cannot claim that we would make incorrect decisions if the artefacts were not completely transparent. Let’s do a quick recap. There are three Scrum artifacts: the product backlog, the sprint backlog, and the increment. Each Scrum artefact contains a commitment to ensure it provides information that enhances transparency and focus. For the product backlog, it is the product goal. For the Sprint backlog, it is the Sprint goal. For the increment, it is the definition of done. Three commitments are mandatory. They enhance transparency and focus. The product owner works with the Scrum team and creates the product goal. The product owner is accountable for the product goal. The entire sprint creates and is accountable for the sprint goal. The entire Sprint team creates and is accountable for the definition of “done.” Thank you for watching. In the next video, we will talk about the product backlog. Stay purposeful.
23. The Product Backlog
What is a “product backlog”? It is a list of ordered items. It is the single source of work undertaken by the Scrum team. But how is this list ordered? That’s the question. Based on what? and the answer is based on value. It is ordered in a way that maximizes the value the product delivers. You remember that the product owner is accountable for the backlog in its ordering.
The product owner wants to put the items that would bring the most value at the top of the backlog, because the developers would then select as many as they believe they can get done during the sprint. Yet it is a collaboration with the product zone. But the developers have to select items from the top of the product backlog. And for that reason, we want those items to be ready for development. And how do we do that? Well, first, if an item is too big to fit on One Sprint, we have to break it down into smaller items. And second, we need to make these smaller items clear and precise by adding details such as description, order, and size. This is called product backlog refinement. Product backlog refinement? It’s not an event in Scrum. It is an ongoing activity. We had a rule in the past as to how much time the developers should spend doing product backlog refinement. and the answer was 10%.
Now, this rule has been removed from the guide. The 10% is not mandatory anymore, but I think it’s good for you to know it. Now the Scrum team decides how much time they want to spend refining the product backlog. Now, let’s go back to the attributes of the PBIS description, order, and size. Something important is happening here. You should know that these attributes may vary depending on the industry the Scrum team works in. And with that, I want to say that generally, we want to include nontechnical items in the product backlog. And the reason here is, again, transparency. The script team should be able to easily discuss these items with stakeholders. For example, by the way, a quick question Who is responsible for the size of the PBS? I hope you’ve answered the developers. They do the work, they do the sizing, and they calculate their velocity. Next, the product backlog is never complete. It is dynamic. In the past, we said it was considered to be a living artifact. It constantly evolves. Since the product backlog is never complete, the Scrum team does not wait for completion before starting the first print. The 2020 Scrum Guide has given us a definition of what a product is.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product could be a service, a physical product, or something more abstract. The people behind this Chrome guy are very keen on drawing our attention to this sentence. That’s why they enlarged it to make it stand out. I have solid experience in marketing, and this change makes me very happy. A product is a vehicle to deliver value. The key word is value. Scrum teams must understand that sentence because it is not about the product itself. It’s about the value it delivers. It’s about what it does for end users and the benefits it delivers. And when we have happy end users, then the people who fund the development of the product as well as the Scrum Team will be happy as well. Let’s do a recap. The product backlog is an ordered list of items. It is the single source of work undertaken by the Scrum team. The product backlog is ordered in a way that maximises the value the product delivers. The product backlog is never complete. It is ever-changing and dynamic. One product has one product backlog, one product owner, and one product goal. at any given time. PBIS on top of the product backlog are clearer and smaller than those on the bottom. A product is a vehicle to deliver value. It has a clear boundary. No stakeholders? , or is, or is, or is, or is, or is, or is, or is, or is, or is, or is, or is, or is, or is, or is A product. could be a service. physical product or something more abstract. Thank you for watching. I will see you in the next video. Stay Purposeful.
24. The Product Goal
The product backlog contains a commitment. The product goal What is it? The product goal describes a future state of the product, which can serve as a target for the Scrum team to plan against. The product goal is in the product backlog. The rest of the product backlog emerges to define what will fulfil the product goal goal.
The product goal helps the team stay focused. But what the guide states is that we cannot have two or more product goals at the same time. The Scrum team must fulfil or abandon one objective before taking on the next. So again, one product has one owner, one backlog, and one goal at any given time. Of course, when we achieve a product goal, we set another one, and another one, and another one. We are moving toward those product goals incrementally, one sprint at a time. Some companies would prefer setting up quarterly product goals. That’s fine. Others might want to choose more inspirational long-term product goals. Scrum does not give us the details when it comes to setting up a product goal because they believe that Scrum teams would be able to do that according to their context. As we said earlier, the product owner is accountable for the product goal as well as the product backlog. One of the responsibilities of the product owner is to develop and explicitly communicate the product goal. Now, I want to give you some more characteristics of the product goal. To achieve the product goal, it is not required to complete all PBIS in the product backlog. Each increment moves the product toward the product goal. It is recommended that the product goal be clear and concise. The product goal is measurable.
The scrum team knows when the goal has been achieved. And I have to answer one question you might be thinking about already: is the product goal the same as the product vision? And the answer is that it is possible. But again, that would depend on the context of the organization. My understanding is that, in most cases, the product goal and the product vision would not be the same thing. And you would need to achieve multiple product goals that move the product toward a bigger product vision. Of course, you do that one product goal at a time. So we can still have a vision document if we want. Another question is: can the product goal change? Yes, it can. It can be refined. The more we work, the more we learn. And we might discover information that invalidates the product goal. And we have to pivot in this case. But a similar question is: can the product goal change during the sprint? highly unlikely, but not impossible. Depending on the findings, the product owner might decide to cancel the Sprint. For example, if we have a team, we may encounter a barrier that we are unable to overcome. We cannot move around, let’s say, new legislation. and Again, Scrum does not give us details that tell us exactly what to do exactly.
And they believe that we, as a Scrum team, will make the right decisions depending on the situation. Let’s recap. The product goal describes the future state of the product. The product owner is accountable for explicitly communicating the product goal. We cannot have more than one product goal at any given time. It is recommended that the product goal be clear and concise. Each increment moves the product toward the product goal. The product goal is measurable. The sprint team knows when the goal has been achieved. The product goal can change, but it is highly unlikely for this to happen during a sprint. Refinements to the product goal happened during the Sprint review event. Generally, the product goal is one part of a bigger product vision. Multiple Scrum teams working on the same product share the same product goal, the same product backlog, and the same product. Thank you for watching. I’ll see you in the next video. Stay Purposeful.
25. The Sprint Backlog & Sprint Goal
What is the Sprint backlog? Well, as I said, it consists of three things. First, the spring goal. Second, the PBI was selected for the sprint. Finally, an actionable plan for delivering these PBIS in order to deliver the increment. The sprint backlog is created during the spring planning event, but it is not fixed scope. It is not frozen. Quite the opposite, it changes. We can alter or remove PBIS as long as that will help the team achieve the sprint goal. The guide says the Sprint Backlog is updated throughout the sprint as more is learned. Another distinguishing feature of the Sprint Backlog is that it is highly visible; it is transparent. The Sprint Backlog is a plan by and for the developers. And when I say a plan, do not think of a written document. No, it’s more about the fact that the developers should be able to explain how they plan to accomplish the sprint goal. The Sprint Backlog may include process improvements the team identified during the previous Sprint Retrospective event. It is not mandatory anymore to have such improvements in every sprint.
But still, I do believe it’s a very good practice. What happens to PBIS in the Sprint Backlog that the team could not complete? Let’s say that the time box for the sprint has expired. These PBIS could be implemented. For example, they might be 40, 50, or 60; it doesn’t matter. Maybe 80% are ready. But there might be PBIS that we haven’t started at all. Now the question is: what do we do in this case? Here is the answer for you: We move these items from the PBIS to the product backlog. We do not add them to the next screen backlog. And why? The reason is that the screen team has to consider these PBIS to see if they are still relevant and if they would move the product closer to the product goal. Also, we do not include these incomplete PBIS in the increment. No, they’re not ready; they are unusable, and we do not present them. We do not present them during the Sprint review event. As you are aware, the Sprint goal is the commitment for the Sprint Backlog. But what is the sprint goal? It is the single objective for the sprint. You also know that the sprint goal is mandatory. Each sprint has a goal. The entire sprint team creates the sprint goal during sprint planning.
As with the product goal, the sprint goal helps the team stay focused. If necessary, during the sprint, the developers can collaborate with the product owner to negotiate the scope of the sprint backlog within the sprint without affecting the sprint goal. Remember, we are not allowed to change the sprint goal. If it becomes obsolete, then the product owner cancels the contract. Time for a recap The Sprint Backlog is made up of three items. The Sprint goal, which is the why, the selected PBIS, which is the what, and a plan for delivering the increment are how the Sprint Backlog is planned by and for the developers. The sprint backlog is highly visible. The sprint backlog changes during the sprint. The product owner and the developers may change. We negotiate the scope of the sprint, but this should not affect the sprint goal in any way. We’ve moved the incomplete items back to the product backlog for future consideration. The sprint goal helps the team stay focused during the sprint. Thank you for watching. I’ll see you in the next video. Stay purposeful.
26. The Increment
What is a “product backlog”? It is a list of ordered items. It is the single source of work undertaken by the Scrum team.
But how is this list ordered? That’s the question. Based on what? and the answer is based on value. It is ordered in a way that maximizes the value the product delivers. You remember that the product owner is accountable for the backlog in its ordering. The product owner wants to put the items that would bring the most value at the top of the backlog, because the developers would then select as many as they believe they can get done during the sprint.
Yet it is a collaboration with the product zone. But the developers have to select items from the top of the product backlog. And for that reason, we want those items to be ready for development. And how do we do that? Well, first, if an item is too big to fit on OneSprint, we have to break it down into smaller items. And second, we need to make these smaller items clear and precise by adding details such as description, order, and size. This is called product backlog refinement. Product backlog refinement? It’s not an event in Scrum. It is an ongoing activity. We had a rule in the past as to how much time the developers should spend doing product backlog refinement. and the answer was 10%.
Now, this rule has been removed from the guide. The 10% is not mandatory anymore, but I think it’s good for you to know it. Now the Scrum team decides how much time they want to spend refining the product backlog. Now, let’s go back to the attributes of the PBIS description, order, and size. Something important is happening here. You should know that these attributes may vary depending on the industry the Scrum team works in. And with that, I want to say that generally, we want to include nontechnical items in the product backlog. And the reason here is, again, transparency. The script team should be able to easily discuss these items with stakeholders. For example, by the way, a quick question Who is responsible for the size of the PBS?
I hope you’ve answered the developers. They do the work, they do the sizing, and they calculate their velocity. Next, the product backlog is never complete. It is dynamic. In the past, we said it was considered to be a living artifact. It constantly evolves. Since the product backlog is never complete, the Scrum team does not wait for completion before starting the first print. The 2020 Scrum Guide has given us a definition of what a product is. A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product could be a service, a physical product, or something more abstract. The people behind this Chrome guy are very keen on drawing our attention to this sentence. That’s why they enlarged it to make it stand out. I have solid experience in marketing, and this change makes me very happy.
A product is a vehicle to deliver value. The key word is value. Scrum teams must understand that sentence because it is not about the product itself. It’s about the value it delivers. It’s about what it does for end users and the benefits it delivers. And when we have happy end users, then the people who fund the development of the product as well as the Scrum Team will be happy as well. Let’s do a recap. The product backlog is an ordered list of items. It is the single source of work undertaken by the Scrum team. The product backlog is ordered in a way that maximises the value the product delivers. The product backlog is never complete. It is ever-changing and dynamic. One product has one product backlog, one product owner, and one product goal. at any given time. PBIS on top of the product backlog are clearer and smaller than those on the bottom. A product is a vehicle to deliver value. It has a clear boundary. No stakeholders? well-defined, users or clients? A product. could be a service. physical product or something more abstract. Thank you for watching. I will see you in the next video. Stay Purposeful.
27. The Definition of Done (DoD)
Let’s talk about the definition of them. What is it? The definition of them is a formal description of the state of the increment when it meets the quality measures required for the product. The definition of them is not an artifact. It is a commitment for an artifact.
This is the increment I’ve shared with you before, but I would like to think about the definition of them as a checklist. These are all the points that the scrum team has to check off to say an item is done. When an item is done, it means normal work is pending. It means that the item is usable by the end user. The moment a product backlog item meets the definition of “done,” an increment is born. This sentence says exactly the same thing because, by default, an increment is tested and it is verified. It is usable. The definition of done is a must-in scrum, and it increases transparency. When we say this item is done, all the members of the team know what that means.
If the organization that the scrum team works for has a definition of “done” as part of its standards, then the team must follow it as a minimum. If it is not an organizational standard, then the entire scrum team creates a definition of what is appropriate for the product. Of course, yes, the product owner Now, the product owner and the scrum master have a say in the definition of “done.” The product owner’s input would be related to quality from a business point of view. The scrum master’s input would be related to, say, improvements to the definition of “done.” After all, the scrum master’s main accountability is the effectiveness of the scrum team. And to be effective, they—the scrum team—must have a strong definition of that. And when I said improvements to the definition of done, do you remember during which events we usually discuss the definition of done? I hope you’ve answered Sprint’s retrospective. Good job. The developers are required to conform to the definition of “done.” When we scrum, we have multiple scrum teams.
Now, just a quick reminder: When we have multiple scrum teams working on the same product, we have one product backlog, one product owner, and one product goal. At any given time, we have multiple scrum masters and, of course, developers. But we also have one integrated increment. mutually and the and the and the and the and the and the and the and the and the and the and Time for a recap. The definition of “done” is a formal description of the state of the increment. When it meets the quality measures required for the product, the definition of “done” becomes mandatory, which increases transparency. If the definition of “done” is part of organisational standards, the scrum team must follow it as a minimum. If the definition of “done” is not part of organisational standards, the scrum team must create one that is appropriate for the product. The definition of “done” may be improved during the project, resulting in a higher quality of work. If multiple scrum teams are working on the same product, they mutually define and comply with the same definition for the integrated increment. Thank you for watching. I’ll see you in the next video. Stay purposeful.
28. Recap Of The Artifacts & Their Commitments
Let’s talk about their definition of them.
What is it? The definition of them is a formal description of the state of the increment when it meets the quality measures required for the product. The definition of them is not an artifact. It is a commitment for an artifact. This is the increment I’ve shared with you before, but I would like to think about the definition of them as a checklist. These are all the points that the scrum team has to check off to say an item is done. When an item is done, it means normal work is pending. It means that the item is usable by the end user. The moment a product backlog item meets the definition of “done,” an increment is born. This sentence says exactly the same because, by default, an increment is tested and verified to be usable. The definition of done is required in scrum and improves transparency. If the organisation that the scrum team works for has a definition of “done” as part of its standards, then the team must follow it as a minimum.
If it is not an organisational standard, then the entire scrum team creates a definition of it that is appropriate for the product. Of course, yes, the product owner Now, the product owner and the scrum master have a say in the definition of “done.” The product owner’s input would be related to quality from a business point of view. The scrum master’s input would be related to, say, improvements to the definition of “done.” After all, the scrum master’s main accountability is the effectiveness of the scrum team. And to be effective, they—the scrum team—must have a strong definition of that. And when I said improvements to the definition of done, do you remember during which events we usually discuss the definition of done? I hope you’ve answered Sprint’s retrospective. Good job. The developers are required to conform to the definition of “done.” When we scrum, we have multiple scrum teams.
Now, just a quick reminder: When we have multiple scrum teams working on the same product, we have one product backlog, one product owner, and one product goal. At any given time, we have multiple scrum masters and, of course, developers. But we also have one integrated increment. And the scrum king must mutually define and comply with the same definition of “done” for that integrated increment. Time for a recap. The definition of “done” is a formal description of the state of the increment. When it meets the quality measures required for the product, the definition of “done” becomes mandatory, which increases transparency. If the definition of “done” is part of organisational standards, the scrum team must follow it as a minimum. If the definition of “done” is not part of organisational standards, the scrum team must create one that is appropriate for the product. The definition of “done” may be improved during the project, resulting in a higher quality of work. If multiple teams are working on the same product, they mutually define and comply with the same definition for the integrated increment. Thank you for watching. I’ll see you in the next video. Stay purposeful.
