Sprint planning. Let's talk about this event. So we'll have a good illustration here that actually were useful for our discussion. So in one side we have stakeholders who are the product owner is a key stakeholder and product owner managing the product backlog. Product Backlog is everything that is known about the product. And there was a meeting sprint planning which we are currently discussing.

And during this meeting scrum team should create a sprint goal or goal for the sprint. And this goal should be supported by a number of product backlog items. So for example, we announced some gophers a sprint. And in order to achieve these goals, we need to develop or deliver and number of product backlog items in our history. And once they delivered, this would means a team created a potentially releasable piece of software. So that's how it works.

Let's learn more in details. So, Sprint Planning is time boxed Scrum Wednesdays it's usually the last two, however, for every week of sprint, so for example, if in your case, you have two week sprint, then you can use up to four hours for this event is the default goal for sprint planning is to define the sprint goal. So every sprint planning anyone shouldn't be finished with a sprint goal or actual outcome of the sprint. Planning shouldn't be a sprint goal. And you should have at least work for several days Blount. That's two major points.

And here's a typical characteristic of this scrum team and then the seven. So entire scrum team not only development team, but the entire scrum team should be presented. how other people are also welcome but only in case usually can provide subject matter or advice or information. Team collaborate on the definition of sprint goal and based on that allows the sprint backlog. So we created some goal for the sprint. And of course, in order to achieve a goal, we will need to deliver product backlog items.

That's how it works. And finally, every spring should lead in into potentially releasable software. So is that default requirement for every sprint? So that was short or you as a sprint planning characteristic. Now let's talk more and let's talk about true statements. Actually, that happens during the sprint planning anyway.

So it's true that sprint planning could be finished even work planned for a few days. So the sprint that's absolutely correct. So as long as we're each timebox, but we have worked for a couple of days, we can say that we are good enough and we can finish the sprint binding It's true that sprint backlog is constantly evolving. Yes, it's absolutely correct. And but it's a little bit tricky question, let me explain why. So let's imagine that we have a sprint backlog, which is actually fueled by a number of product backlog items.

And what we're gonna do next, we're gonna split those items into the tasks. And while we're splitting them, it means that our backlog is rolling. So that's the major reason why we are saying that sprint backlog is a Well, it's true that sprint planning should come immediately after retrospective for the previous spring. That's absolutely correct. But of course, don't forget about coffee breaks and human related files. It's true, as that happens, and those a sprint planning team should get clear on the stand on the two major questions.

What we are going to do and how we're gonna do this. So that's the two major questions It's true that sprint planning is time boxed event with a maximum length of eight hours. So yes, we already talked about this but once again, a house is four months to sprint. As long as you have two week sprint you should consider for house and to house for weekly sprint. So where are you? The measure points are in regards to the sprint planning event.

We're using points which are true statements. Now let's talk about false statements in regards to the sprint planning event. It's false statements that product backlog refinement or in other words grooming should be done during the sprint planning and spring for you only as a measure of security. So first of all, let's talk about zero refinement or grooming activity. So what does it mean? Actually requirement or grooming activities is activity when a team actually discusses the poor puzzles a product backlog item and discussing the require Running out and trying to understand what is the purpose of the system and trying to understand whether this item is ready to be developed and whether it's clear from the business standpoint and from the development standpoint.

And this process is permanent in this process should not be limited to the meetings such as sprint review and sprint planning. So that's a false statement. So once again, sprint backlog refinement or grooming In other words, is this permanent process which should not be limited to the fall into events, which are actually stated here, Sprint review and sprint planning. He's full statements that product owner and Scrum Master are not on better for the sprint planning. Both product owner and Scrum Master are among others. So this statement is false.

It's false statements and sprint planning is internal event and people outside the scrum team should not attend So sprint planning is not internal. And as long as someone can have expertise, some information that is important or useful, we can help this person invited out. He or she will share his or her experience about subject metro area. So that was a short overview of the sprint planning event. And this event is considered as opportunity for inspect and adapt. I hope you have a better understanding of the purpose of this event now and made sure of theoretical as they went.

Well, that's my one LS book about other Scrum events.