PSPO Versus PSM

0:00Welcome to the Professional Scrum Product Owner Course. This is skill number one and I hope this isn't your first time training with me. If it is, congratulations! You have found the best and most humble but really the most awesome project management instructor there is at CB T Nuggets. Now when I say humble and awesome, probably don't go together but I like to have a lot of fun and that's going to work in your favor. If this is not your first time training with me, welcome back.

0:30I hope you've had a good time. Something must be happening right because you came back. Okay, enough of that silly stuff. Let's talk about the PSPO 1. There's a lot going on with the Professional Scrum Product Owner that is very similar to the Professional Scrum Master 1 course which I previously taught. You may want to consider looking at that one first and then coming back to this one. That one was 10 skills. This one's going to be 6. The first skill is all about comparing one to the other so we can figure out what that gap is and the knowledge that you need to understand.

1:08I mean let's face it. If you're going to get your PSM1 cert, you may as well get the PSPO1 as well. 2 for the price of 2. I think you know what I'm talking about. Let's take a look at it. Right out of the gate, I'm going to jump off this screen and I want to take you to a skills comparison that scrum.org is put together. So hang on. I'll be right back. Okay, so here we are. This is Professional Scrum Training Competency Mapping. It was put together by scrum.org. It has all of their certifications. We are going to deal with these two right here. PS M1, Professional Scrum Master and Professional Scrum Product Owner 1. PSM is more basic than PSPO. I'm going to try not to blow these acronyms up too bad but it may happen. But let's scroll down and take a look at these so you have an idea of what you're dealing with because I don't want you to be confused between the two. So let's scroll down a little bit. Let me grab the cursor.

2:12Here we go. So if you look over here, you have empiricism and scrum values, scrum team events, artifacts. All of these are basically the same until you get down here where it talks about scaling. And that is not supposed to be that fat. I have pen problems and I don't know why it happens. So let me just get rid of that one. And let's see if we can do this at a level that makes a little more sense. So there we go. You have scaling for the Professional Scrum Product Owner which is different from the PSM. You can see it's blank. But let's remove that and go down just a little bit more. Let's keep looking. So when you get down to the focus areas, you'll see that self-managing teams, fac ilitation and leadership styles is pretty important on the PSM1 side because it's the more basic course.

3:05You can also see that teaching, which I thought was pretty important in the PSM course, comes up for the scrum product owner course as well. They're simply teaching something a little bit different. So let's clear that and boogie on down the road here a little bit more. Here we go. And here you can clearly see there are two key differences here. Well, you have the business strategy down here for the product owner and you have stakeholders and customers. And we're going to talk about these quite a bit, but I'm going to give you just a taste of it right now. As far as stakeholders and customers, the product owner is the voice of the customer. They represent the internal and the external client. So they need a very clear understanding. In fact, an in-depth understanding of what the client is actually trying to accomplish. And if they understand that, that should lead them right back here to the business strategy. What is this product, this result, going to mean for the business? The business strategy should be something like capturing new revenue, decreasing customer churn, opening new market spaces, whatever it is. There should be a strategy that takes us from the present state to the future state. And obviously the product owner as the voice of the customer

4:21should clearly understand that and then be able to articulate it, with the right word, articulate it to the rest of the scrum team, which is the scrum master and the developers. And if you think about it, that will take us all the way back up here to teaching. That's probably how those are tied together. If not, it sounds really good to me. But let's clear that and go down just a little bit more and see if there's any other obvious differences. You get down here, you can see there's quite a bit for emergent software development, technical risk, continuous quality.

4:59There's a little bit less over here for the PSPO. Why? Because I think if it is more of a strategic level role, whereas the PSM role is more of an operational slash tactical role. One is looking down very clearly at the high definition, the details, the code, the development, while the other is looking upward and outward, the business, the vision, the clients, the future state. That's why there's a difference there. And let's go down one more time as soon as I remember how to do it. And that's it. That's really where the comparison's in. You'll see that there's a little bit over here with the big fat pen. I have no idea why that is automatically changing. And if you've been in training with me before, I haven't figured it out yet. I don't know what it is about my computer that does that. I feel like it's doing it on purpose just to see if I can cope. It's really testing my EQ. Do I have the emotional intelligence to hold it together? And the answer is most days I do. But if this keeps happening, who knows? But I digress. If you come back over here, you'll see there's a little bit for organizational design and structure, evidence-based

6:15management. And there's a little bit less over here for PSPO. So I'm going to leave this right here for now. And let's jump over here. I think I'll do it in the next nugget. Hold that thought. We'll do one more comparison when we talk about the scrum guide reviews, the shared competencies, and all that stuff. Yeah. This is a good place for a break. And I'll be right back.

0:00Welcome back. I thought that was a rousing introduction. Sorry about the fat pen problem. I'll probably Google it or chat GPT it and it's probably going to tell me user error. I get that a lot. But here's what I want to look at now as we compare these because I really need you to understand the differences between PSP, PSM, Professional Scrum Master, and the Professional Scrum Product Owner. You're thinking and doing at two different levels. But the foundations of what you're doing are almost exactly the same.

0:31So let's check this out. In fact, let me zoom into this a little bit. Let me come over here. Here we go. Let's let's sit at 150% there. Let's just come down a little bit. Let's grab the pen one more time. Let's try it below and see if I can figure this out. So your Professional Scrum Competencies come up all the time. You have empiricism, scrum value, scrum team events, artifacts done, the definition of done. But let's take a look at what happens when you come back over to the Professional Scrum Product Owner. Let's zoom in on. Okay. So this one is zoomed in too. And let's see if they apply. Well, not quite. Let me clear the screen and just do it one more time.

1:14I feel like we just had empiricism scrum team events, artifacts, and done. They are virtually identical. And if you just look down here, self managing teams for developing people and teams, and then you come back over to the PSM, you have self managing teams, facilitation, and coaching. These were different than the PSPL. And if we go just a little bit further, and I promise you, this is leading somewhere forecasting, release planning, product value, the backlog management stakeholders and customers. And now let's switch gears one more time to the PSPO. We had forecast and in release planning, product vision, value, backlog management. But here, you have business strategy, stakeholders, and customers. So again, the key difference here is not that the information is vastly different. It's your focus. It's your way of thinking.

2:16We're moving from the strategic level of thinking for the PSPO to the PSM, which is for the more tactical thinking, doing thinking, think big, think strategic for PSPO, and think tactical for PSM. There are also some differences in your resources. And I may as well just show you now, because these resources are super important. For now, let's just leave PSM alone. Let's just focus on PSPO. And let's come down a little bit. This is really important. If you come all the way down, you have practice assessments. Now you had these for PSM, but it's different for PSPO because the information is given to you in a different way. These practice assessments, and I'm going to drop this link below. I really need you to use these. And if you sat with me in a previous course, you know these are pretty important. These are going to expose you to the kinds of questions, the kind of information, the kinds of skills that you need to understand for the actual exam when you sit for it. The Scrum Assessment, the Open, as well as the Product Owner

3:33Open, fantastic. If you go there, I suggest you do it. Start testing maybe one a day just so you can start to expose yourself to the kinds of questions you're going to see on the real exam. I think a huge key to passing the first time and passing without, you know, praying, not that I'm against prayer, but I don't think prayer should be your primary exam strategy. One of the keys, in my humble opinion, is taking the practice assessment. I've had both of these certs for a long time , and I took the the Product Owner Open the other day, and I missed one. Why? Because I wasn't paying attention.

4:12I became complacent. I was zipping through it. I got it done in about eight minutes, and I missed one because I simply wasn't reading it. I was thinking tactical when I should have been thinking strategic. So do yourself a favor. Do me a favor. Start looking at these assessments. They are free, they are awesome. Let's see where it takes us. Now, I can only take you so far because of copyright rules and all that, but I will take you as far as I can. And again, I 'm going to drop this link below. Start using it. Maybe one a day until you're ready for the exam, one every other day as you study, and that's going to serve you well. So let's click the link to the Product Owner Open and see where it takes us. Now, it's going to tell you all the information you need to know, PSM 1, the learning path and all that stuff. The key difference here is, for this one, you get 15 questions. For PSM, you got 30. 15 is plenty. Now, if you take these over and over and over again, you're going to see the exact same questions. But again, one a day is probably going to do it. I'm going to take you to one more screen I think I can before I start getting warned. And

5:28again, I'm not trying to duplicate or copy anything for them. I just want you to understand, if you start this assessment, it's going to start spinning it up. Now, this is as far as I can take you, but this is pretty important stuff. Let me zoom in a little bit more so you can see it. Let me come back up here. I think that's probably going to do it. Let me take you a little bit further. There you go. Got your number of questions. 15, you've got 30 minutes, you are not going to need 30 minutes. I promise you, you need to stay on the test page. If you click off of it and go some place else, and it's going to stop your test, you're going to have to restart it. You have to start and finish it at the same time. You can't come back. You only have one question per page. You can go back and change your answers. Now, it's not going to let you finish if you don 't answer any. Let me rephrase that. If you have some you didn't answer, it's going to make you go back and guess. That's probably a better way to say that. But why would you want to leave any of them blank? And the answer is you wouldn't. If you don't know what it is, tag it for review, guess, and just complete it.

6:39It will let you understand exactly what happened because at the end of this, you're going to see all the questions, the ones you got correct, and the ones you got incorrect. Obviously, click on the ones you got incorrect and understand why you got them wrong. All right. So , I'm going to stop right here. This is a good place and one more time and not the final time. Make sure you are using these assessments. They are invaluable to passing. I'll see you in the next nug get.

0:00Welcome back. It's time to talk about some of these professional scrum product owner competencies. And here's the rub. I'm kind of in a tough spot. On one hand, I'd like to say, look, there's a bunch of foundational stuff I covered in the PSM, the professional scrum master one course. Go check it out so we don't have to do it again. But that means you'd also want to be PSM one certified as well as PSBO one certified. And that may not be the case. So what I'm not going to do is try to put a square peg in a round hole and force you to do my job, even though that would make me incredibly happy. So instead, what we're going to do is we're going to take a look at some of the foundational stuff that spans both of them. And then I'm going to show you exactly where it's at. I definitely recommend you do some homework, you do some extra reading, probably 20 or 30 minutes will cover it. And you will be as cool as a cucumber. Let's take a look at it. Let's grab Mr. Mouse right here. I'm back on that same page for the PSPO competencies. We already saw this earlier understanding and applying the scrum framework. Let's just click this link. And I'm going to go through some of these real quick and show you what's important, why

1:19it's important, and I'm going to cut right through the nonsense and get right to the really important stuff. So let us click on empiricism. I started to grab Mr. Penn and talk about this just a little bit. Let me see. You know what? I got fat pen one more time, but I got you this time stuck at all. You're trying to get me not working this time, buddy. I won. Got it. And you realize you're talking to an inanimate object, right? Yeah, I understand that. But I won. So what is empiricism because it comes up all the time in the scrum world. It's philosophy that all knowledge originates in experience and observation. There is a really good paragraph right here, which blows my mind.

2:06Empiricism is contrasted with rationalism, where rationalism is perspective that knowledge is developed by reason, analysis, or thinking things through. Whenever I think of rationalism, I think of waterfall projects or predictive, where you have to think everything through because it's so heavy in engineering many times. And it just makes sense. There are so many things that can go wrong. The scope many times is so well known that the only thing you really need to do is figure out which goes first, the cart or the horse, A, B, C, D, E, F, all the way to Z string it together and it makes sense. It works very well. We're not talking about the same thing here . We are comparing apples to oranges. So when they talk about empiricism, they're simply recognizing that some problems are too complex to be solved by reason and analysis alone. Complex problems require that we experiment our way to the solution, meaning we figure it out along the way, which means for PSPO, for scrum in general, you have to simply accept the fact that change is going to happen

3:22over and over and over again. And as soon as you embrace that, the easier that change is going to be. Because we are going to talk about something called TIA, transparency, inspection, and adaption. Scrum is transparent in all of their artifacts and all of their commitments. Then we inspect all of those things along the way we get feedback and then we adapt to it. And it is this constant cycle that kind of looks like this ride here. We do something, we look at it, we inspect it, we adapt to the results. And then we hit repeat. We do something, we inspect, we adapt, and then we hit repeat. And it just goes on and on and on. Because think about it, for a waterfall project, you're aiming at an end result two years down the road, maybe 10 years down the road, depending upon what it is. But in the scrum space, a sprint can only be no more than four weeks long. So you have a chance to adjust on your aiming point no more than every month. And since there's a daily scrum for 15 minutes, the team, the developers, they have a chance to redevelop the

4:39correction to re-aim their focus every single day. Think about how many fewer errors you're going to have between everyday adjustments versus one major milestone adjustment every month or every two months or every six months or a year. You're going to be a lot closer to where you're trying to get with empiricism, transparency, inspection, and adaption. And this is going to come up a lot. So let's keep going. What is complex? There's a really good slide here. I need to find it because man, it is a brain burner. Here we go. This is so good. Whoever came up with this deserves some kind of an award because probably got one too. This is fantastic. We can think of simple, complicated, and complex using this right here. Simple where most things are known.

5:31I always think of waterfall that way to complicated where we know what we don't know. We have known unknowns, but then you have complex where you have unknown unknowns. And that's where the value of scrum comes in right here. Most things are known. The unknowns are known. We know there's a bunch of stuff we don't know about that. You see this a lot in engineering type work as well. In cutting edge technology, anything that requires a lot of analysis, but then you have complex. The unknowns are simply unknown. We accept it. We drive towards them.

6:10We experiment along the way, which is where empiricism comes from. Again, I think it's amazing. I'm probably a project nerd in my belief, but I don't care. I think it's cool. Let's take a look at it. There's some examples here. Software run a bill that succeeds consistently. Medicine, treat an upset. Stomach, home, baking, cookie, shopping for groceries. These are things that are well known. And if we go just a little bit further to complicated problems, then you have things like software, fix a non-trivial bug, extend a feature. Okay, it's a little complicated.

6:48Medicine, diagnose a new blackage or perform a surgery, do something kind of new, kind of dangerous, kind of interesting, buy a house, save for retirement. You can see it, but you don't see all the steps to get there. It's complicated. Well, then you get too complex. We know we need to go some place else. We're not really sure how to get there, but we know we have to go. So you have create a new product for a new market. Well, how do we do that? Find a cure for pancreatic cancer, a new cure.

7:23And man, raising children. I have four and there's a lot of books written about raising kids, but every single one of them is different along with every single parent, every single day, every single moment. And so it's even if you had a crystal ball, you wouldn't be able to get any one of these done easier than the other. Probably raising kids is a hardest , but I'm going down mad cow lane. Just leave me alone. And one more, why is scrum important? Well, right here, it encourages a team to continuously experiment, inspect and adapt.

7:59That is Tia, transparency, inspection and adaption. And when we finally get to the flow of the scrum events, you'll see that with the product backlog, the product goal, the sprint backlog, the sprint goal, the working increment and the definition of done. It all surrounds transparency , inspection, and adaption. It's going to be really important you wander through some of this stuff throughout this course here and there and everywhere. It's going to serve you because these kinds of questions are what I call softballs on the exam. But if you aren't familiar with it, you might get thrown.

8:40So don't be surprised when I drop this link below to give you an opportunity to check out in paracism some more. So hang on, we're going to look at some other competencies when we come back.

0:00Now that we've talked about empiricism a little bit, let's move on to some of these other focus areas. Scrum values, I'm not overly concerned with this one, but let's just go through them real quick. You can see them over here. Courage, focus, commitment, respect, and openness. There's nothing wrong with that. There are some great examples here. Well, the help if I would move that circle, that's a funny thing about using a digital pen. Sometimes you remember to take the stuff off that you wrote and sometimes you don't. Now the Scrum team hasn't changed for the PSPO. Let's take a look at it.

0:35This stuff is actually pretty important. Scrum team is typically tenor fewer. You're probably going to see that on the exam. Don't be shocked. They use a Scrum framework to create something valuable. Now this is the Scrum team. You've got a product owner, one. You've got a Scrum Master, one, and you have some developers, probably seven, eight of them. That'll give you about tenor fewer. Everyone is accountable. The whole is accountable for creating a valuable, useful increment in every sprint. There you go. Everyone has their own accountabilities within their area of work, and let's take a look at those real quick. Let's come down here and look at the product owner, which this is really about. Here we go. The Scrum guide, and I'm going to show you where that is, well spell these out. Effective backlog management, including developing and communicating the product goal. That's one of your commitments. Communicating the backlog items. Why?

1:39Because the backlog items are then checked out by the developers and they select those items. They clearly understand to pull into the sprint backlog. So if they aren't straight in the product backlog , they really can't be pulled into the sprint backlog. So they can be turned into a useful working increment by the end of the sprint. That means a product owner has to order the backlog items. Why? Because he or she is maximizing value. That looks terrible. Let me try that again. They are maximizing value, one of their key responsibilities. Why are they trying to maximize value? So they can produce the greatest something in the shortest amount of time based on transparency, inspection, and adaption. Why are we adapting because of feedback? That feedback loop is in effect all the time.

2:37Stakeholders, customers, end users, all being funneled to the product owner, which is why the product owner is the voice of the customer, which is why the product owner is tasked with maximizing the value in the backlog. Oh, look, it's transparent, visible, understood, because of Tia, transparency, inspection, and adaption. And if you train with me before, you know that I will talk about this until you are sick of it. And I don't care. Is there anything else useful here?

3:13Let's back up a little bit more. I want to leave the product owner alone for now. Let's talk about the developers. We're going to talk about the product owner some more. Well, what do the developers do? Create a plan for the sprint and the sprint backlog. They're the ones doing the work they adhere to the definition of done. Think of it as the quality standard. How do we know the useful increment is actually useful in working because of the definition of done. They adapt every day through the daily scrum. I lost my mind for a minute, and they hold each other accountable as professionals. And let's make one more jump back to the scrum master, and then we will eventually make our way over to the product owner. This is really important stuff because it all comes up on the exam scrum master is accountable for their effectiveness and establishing the scrum. Basically he or she makes sure they adhere to the framework. And if there are anything any impediments, any blockers, they get them out of the way so they can do their work. The last thing a scrum master wants to see is the scrum team get to the end of the sprint and they don't have a working useful increment. That means something got sideways

4:32and that sprint for all intents and purposes, purposes, if you will, you know what I'm saying, failed. That should not happen. To help him improve, let's see. They understand and talk about the theory of scrum, the purpose, why it's beneficial, delivering value, the why. Excellent scrum master's helped the team drive and deliver value. Pretty simple. Again, I don't want to stay on the scrum master too much because this one is all about the scrum product owner. However, you need to understand the interactions between the product owner, the developers, and the scrum master because there are interactions among them as a team and as pairs. So we'll talk about that in the next nugget. So hang

0:00Okay, in this section, we're going to talk about the scrum events. It's part of the scrum framework. Super important. Let's jump right into it. There are only five scrum events. So easy peasy, lemon squeezy. You have the sprint, which is the umbrella encompassing the others. At the beginning of it, you have sprint planning. That's where you plan for the sprint . That's why it's at the beginning. Every day you have a daily scrum where the team gets together and they talk.

0:32Well, at the end, you have a sprint review. Here you are looking at the increment. Think product, think result. Think whatever this thing is we're supposed to have created during this sprint. So that one's all about the product. Well, after that, you have the retrospective, which is all about the process and the people. Are there time boxes? Yes, there are. There's a really cool graphic right down here to help explain this in greater detail. So let's take a look at it. Let me grab Mr. Penn. Let me see if he's going to act right. I think he is.

1:10So once again, let's talk about the sprint. Where did it go? We know the sprint is the umbrella. It encompasses all of these. Well, a sprint can't last no more than four weeks, but sometimes they say one month. I prefer four weeks. It's just my preference. Most of them are simply two weeks long. But again, the real important part is can't be no longer than four weeks or one month. Dep ends on how you're looking at it. And it encompasses the rest. Well, at the beginning of it, you have sprint planning.

1:51It can last no more than eight hours for a one month sprint. Obviously, if you have a shorter sprint, you're probably going to have a shorter sprint planning meeting, if you will. Every day, there is a daily scrum. It is now my apologies. Let me take a half step back for sprint planning. The entire scrum team is their product owner, scrum master developers. Now we can move forward, my apologies. Sometimes I just shift gears really fast. It happens. Back to the daily scrum.

2:28It can only be 15 minutes long and it is only for the developers. It usually happens at the same time in the same location to reduce complexity during the sprint, which is why they do it. Can they move it? Sure, they can. Do they skip it? Not very often. If they do skip it, the scrum master gets involved and says, hey, why are we skipping this? You know it's part of the framework. You have to do it. And they're basically answering three questions. What did I do yesterday?

2:59What am I going to do today? Is there anything impeding me from doing that? There's no set format other than that they actually have it. At the end, the entire scrum team and the stakeholders think customers get together for the sprint review. And here they are looking at the product. This lasts no more than four hours for a one month sprint. And they are looking for a working increment. In one example, let's say they have a software app for banking.

3:31Maybe this sprint was all about being able to create an online account from an Android phone and an iPhone. So that's what they worked on this month. When they get to the sprint review, they actually show the customers, hey, look, here's my Android. Peep, peep, peep, peep. That's the sound of an Android. And they actually show them that they have a working increment, the app, the frame, the shell, whatever you want to call it, will actually allow someone to go online and create an account for that bank. And then they do the same thing for their iPhone. Great. Now that they have a working increment, which is what they were driving towards, now they will get feedback, which they will incorporate into the next sprint, if necessary. Again, think Tia, transparency, inspection, and adoption. After they're done with the review, they have the retrospective. This is all about the people in the process.

4:33What was difficult during the sprint and why? Was it a person? Was it a group of people? Was it a process? What did we learn that went really well? Excuse me. What did we learn that could be better? They incorporate that into the next sprint because they're always trying to be better. Are they perfect? No. No one is perfect, but we can aim for better all the time through empiricism, transparency, inspection, and adoption. So let me clear the board. Again, this is a really good graphic. I'm going to leave this link here so you can find it. This thing is fantastic. All of this is within one more time the sprint. So there are your scrum events. One, two, three, four, five, to show you that there are five. This is one month as a time box. These are your time boxes over here.

5:37These come up on the exam all the time. Let me show you how. Let me come down here. So there are anti-patterns, meaning you're doing things that aren't part of the scrum framework. So let's say the product owner says, "Hey, let's go ahead and have a six-week sprint because we can get more work done." Well, the product owner wouldn't say that except on the exam and only to trick you because it's an anti-pattern. You never want to exceed your time box. Or the product owner only listens to the senior developers. It's not going to happen.

6:10But they will use that on the exam to try and trick you. Or the scrum master acts large and in charge and turns everything into a status meeting or the product owner facilitates the daily scrum or demands that the developers work on certain things from the product backlog. All of this is nonsense. It simply would not happen. And if you see something on the PSPO1 exam that looks like it's baloney, it probably is. Slap it between some bread, put some mustard on it, and eat it because that's all it is, baloney. Other things that might come up. Team members just realize there's a problem and they wait until the next sprint to talk about it or do anything about it. They're not going to do that because of TIA, transparency, inspection, and what?

6:57Adaption. I already said that the scrum master acts large and in charge like a project manager. That's another anti-pattern on the exam. There are no project managers on the scrum team. If you see that, it is WR-O-M. Wrong. Don't fall for it. And the scrum team members don't show up or they have different events or they have different people involved, not part of the scrum team, or they're passive. They don't participate. Again, there are some anti-patterns that scrum will try and trick you with on the exam. Don't fall for it. So here 's my takeaway advice.

7:36Learn the basics of the five scrum events and their time boxes, the participants, and you're probably going to be okay.

0:00As we continue this review, let's talk about the Scrum artifacts. There are three easy peasy. I really like this section because you have artifacts and you have commitments. Meaning the product backlog is the artifact and the commitment, the results of using that artifact is the product goal. Product backlog, product goal, it kind of makes sense. Then you have the sprint backlog and the sprint goal. You see that pattern?

0:31Sprint, sprint. Yeah, I know you do. And then you have the increment and the definition of done. Definition of done, again, is basically the quality standard, the functionality standard that you're trying to achieve in the working increment. And here's kind of how it works. The product backlog, think of as all of the functionality, all of the characteristics that they want in any particular app. Okay, and the product owner controls it.

1:02Well, the items at the top are going to be the most detailed and/or the most important to the product owner who is representing the client as the voice of the customer. He or she is going to work very closely with the developers to move some of those important items into the sprint backlog. Now, to sprint backlog, those are the items they're going to work on during the sprint, the developers. Typically, you can think of them as story points.

1:34And a story point is really nothing more than a level of effort. A story point of one means low level of effort. It's not a one-for-one, one-story point is one hour. It's not that kind of thing. It's about level of effort. A level of effort of one story point is pretty simple. Three, also pretty simple. Five, a little more complicated. Then you get into eight and thirteen. And they're rarely going to go beyond that because it's just too big. It's typically not well enough understood. And remember, a sprint only lasts so long as a scrum event.

2:08They hit what's called a velocity to deliver a certain number of story points every sprint. Well, the first sprint, they hit twenty. And the second sprint, they hit twenty-two. And the third sprint, they hit twenty again. And the next sprint, they hit twenty-one. This is going to come up again in forecasting later on in this course. Well, why do they do it? Because the team knows their capacity to get work done to achieve the quality standards that they're trying to achieve in each sprint.

2:39So they are not going to take too many items from the product backlog and bring it into the sprint backlog and then not be able to deliver a working increment. A smart team is not going to do that. A product owner is not going to push him to do it. And a scrum master is going to be paying attention to see why, if at all, it may ever happen. And if he or she sees it's about to happen, they're going to shut it down, Jackie Brown. This is a synchronicity of ideas and needs.

3:13So again, everything is into product backlog. The stuff for this particular sprint is going to be in the sprint backlog. And when it's done, they should deliver a working increment. Easy peasy. Let's clear that one. Man, I don't know why I'm saying easy peasy so much, but I really am and I need to quit it. So let's do a quick look at these real quick. The product backlog is what I said just a moment ago. Here's a great representation of it that I was saying.

3:44You have sprint one, two, and three, four. And again, this can change at any time because of backlog refinement. But the stuff that's really well known or really important is going to be up here at the top, which is where the developers are going to be selecting items from that they can pull into their sprint backlog. Super duper cool stuff. And man, I am really a nerd for this. I know I shouldn't be. I don't care. Single, transparent, current, ordered. Let's back out of that one.

4:15So we have a product backlog, which means we have a product goal. It is the commitment, meaning it's the focus for the scrum team and the target by which progress is measured. That's really it. Really easy to understand. I'm not even going to drag that one out. So again, artifact commitment, product backlog, product goal. Let's back up and take a look at the sprint backlog and then the sprint goal. Here you go. The easiest way to explain it, as I like to say in Tennessee.

4:49Here's a can ban. This is the stuff we need to do. This is the stuff we're doing. That's the stuff that's done. And what you want to see is all this stuff get moved over there to ensure they have a working increment. Typically, if they get it there, they get it done. If they get it there, man, I got to stop watching he-haw reruns. Let me back up over here for just a second and see if there was anything else. Why is it highly visible? This is also a good one. Well, it would be better if I had to pen here.

5:19Why is it highly visible? Because of Tia, transparency so they can inspect it so they can adapt to it. I love that. A real-time pitcher. And yes, I'm overly excited about this. I don't care. Sprint backlog, sprint goal. This is what they are trying to achieve. Here you go. There's the commitment for the Sprint backlog. Again, how can progress be measured? And we're going to have some more examples of these as we go.

5:51Let's do one more artifact, one more commitment, and then we will shut it down because there's only three. The increment. I like this. The latest version that conforms to the definition of done. Anytime you had an app on your phone because we all have plenty and you saw you open the app and it said, "Oh, an update is available." Version 3.4.2. Well, that's the latest version of the product that conforms to the definition of done. Maybe they fixed the background color or maybe they offered you another function or maybe they allowed you to hook a billing app to it like PayPal or Venmo or something like that or maybe they allowed you to upload a profile pitcher.

6:35That's what increments do and that's why it must work during the Sprint review. They have to show that it works. And there are some really good examples down here. Products for sale to the public, a mobile app or a hairshaver delivered to the public are internally internal software applications, maybe some sort of collaborative tool. Anything else? No. Then taking a look at the definition of done and that will wrap this section up .

7:07Well, what is it? And I feel like I said this before, it's basically the quality standards. Think of Six Sigma. Six Sigma means out of one million possible defects, you have something like two and a half errors. I think it's two and a half errors out of one million possible defects. That's crazy. You can measure the speed of your vehicle by looking at the speedometer. You can measure how great your sheets are by looking at the thread count. You can measure the awesomeness of your socks if you have a whole pair.

7:42Two socks, one for the left foot, one for the right foot and that works really well for most people except for those people who may not have both feet. But you get the point and I'm not picking on anyone, I'm simply telling you if you can't measure it, how do you know it's done? Because quality is not an accident. Quality is an intentional act and that is why the commitment must be the definition of done. If you can't define done, you can't achieve it.

8:15So let's leave it right there because guess what? For this section, we done.