Spring backlog. Let's talk about these major Scrum artifact. So we have the full on illustration here, we see a list of user stories. And we see that each user story splits it into a number of tasks. And that's a good example. That's how a normal sprint backlog will behave.

So we're putting something into sprint backlog, and then we're decomposing it to a number of tasks. And only after that the element team normally start working on the tasks. So let's talk about the major characteristics of the sprint backlog. sprint backlog is a prescribed Scrum art department so it's mandatory for Scrum. sprint backlog evolves during the sprint. We recently talked about splitting product backlog items into tasks, decomposing them answers the major reason why we are saying that sprint backlog evolves.

And finally sprint backlog items are considered to be completed when asked And is done based on definitional done settled by the development team. So it's important that development team agreed and definition of done or in other words, list of roles, which are required to be passed successfully before any item can be considered as done. So it's very important. Let's talk about the major statements which are true regarding the sprint backlog is chosen development team tracker is a progress towards the sprint goal by resolving the sprint backlog items. So it's YouTube's development team to track the progress and to reflect this progress on the board. On the other tools as long as they are use attempt of course, to communicate the progress to Scrum Master and product owner as long as it variety from what is expected.

So that is one of the duties of the development team. It's true that all the development team could add or subtract as items also sprint backlog. So it's also sold the correct sprint backlog should be managed solely by them development team. So not product owner, not Scrum Master or anyone else could make manners short change Thompson tours is pretty much what this should be managed by the development team account. If we're speaking about abstracting items or any items at sub sold and fine as long as these activity actually support the spring goal and makes potentially reusable software comes true. So these are the major points which need to be considered when we're adding something or subtracting something from the sprint backlog.

It's droves that sprint backlog items are shared between the entire development team. So let's absorb the correct and this statement is more about responsibility. So in Scrum, all the responsibility belongs to the entire development team. And there should be no situation when a particular member of the development team saying or claiming that particular item owner or belongs to him or her. That's not acceptable in Scrum, all the items belongs to the entire development team. Now let's talk about false or incorrect statement regarding the sprint backlog.

It's false statements that sprint planning should lead to the well defined sprint backlog which should stay unchanged during the sprint. This statement is not correct, and there are at least few major reasons why Let's review them. So sprint planning could be finished when we have prepared to work for a couple of days only. And it means that later, when we will complete as we prepare to work, we will add more work and this will cause change towards a sprint backlog. The second reason is that normally when we already product backlog items into sprint backlog, we are decomposing them, we are splitting them into task. And that's the second reason why sprint backlog will not stay in change because by splitting, the product backlog items will cause change towards the sprint backlog cells.

There's a second major reason it's false statement that if for whatever reason development team haven't finished all the items of the sprint backlog, such sprint should be canceled. This statement is not correct as well. And normally what should happen the weldment you should notify product owners that a number of product backlog items haven't been finished and product owner will return back as items into product backlog and reprioritize them accordingly. So that's how it normally works but sprint should not be canceled. So the statement is not correct. It's false that a gel is about to change.

So as a product owner can replace item with equal size in sprint backlog while sprint has arrived, so this statement is not correct as well. And there are three reasons why it's true that the gel is about change cells. That's absolutely correct. We were and gel doesn't support Charles, by replacing Samson over sprint backlog, product owner could create Charles because more likely is going to be unexpected change for the development team. If product owner want to have some particular product backlog item to be taken into the weldment as soon as possible, then such an item should be prioritized accordingly. And during the sprint planning, product owners should ask development team about that.

So they can consider this item for sale development, but not chose here, please. So that's the first reason. The second reason is that we know that all the items before they can be taken into a sprint backlog, they should pass a refinement or grooming activity. And as always a big chance that if something cool replace it, then such an item may not been verified or groom it before. And if it's true, then such replacement could cause big problems for the development team. So it's another risky point why you should not happen.

And finally, the short thing is that sprint backlog managed by the wall of Monday morning, but not by someone else, including the product owner. So that were three major reason why this statement is false. It's false statements as items in sprint backlog can be replaced by the development team. So we already talked about there replacing house items by the product owner. And we realize that product owner should never do this. So product owner can't replace items towards the sprint backlog.

But what about the weldment? team? We know that they're augmenting could add new items to sprint backlog and subtract those items from the sprint backlog, but can they actually replace something? And the answer is no. And the main reason is why because when we speak in about replacement, we consider that scope is going to change. So if we replace something, then we are about to change the scope.

And of course, this will affect the spring goal. So this action is not desirable, and therefore this should not happen. So replacement is prohibited even for the development team as well. And let's finish this lesson by really Following the recommendation, according to this deep, it's good to keep good communication good cooperation between the development team and the product owner, because this will lead to efficient work. So, all the change to our sprint backlog calls the change store. Sprint activity should be discussed and collaborated between development team and product owner.

That's generic suggestion. Now let's talk about next prescribed Scrum artifact product increment.