In this lesson, we're going to talk about a couple of important concepts. One is sprint zero, and the other one is released plan. So what exactly does sprint zero mean? Remember, we have agile that basically this is I want you to kind of go through the Agile lifecycle. So hopefully this will kind of put it in perspective better. Remember we have product backlogs in from the product backlog that we have created.

The product backlog is basically basically a bunch of stories with the estimates and the priorities and other things if you will, if you remember, and then you know from the product backlog at the start of the sprint, you basically take what stories are going to be done during this sprint, right? So that becomes part of the sprint backlog. And that is done. Those stories are being worked on during the sprint which is usually Two weeks long, two to four weeks long, but typically two weeks down. And then everyday you're meeting for the scrum. And then at the end of the sprint, you have potentially shippable product, right?

So that's kind of the life cycle of, of Scrum, and if you will, and then basically it repeats in then after the first sprint is complete, you get into the second sprint, you go through the planning, and you know, you create the sprint backlog and you know, over and over again until you have the release complete, if you will, right. So that's all well and good. But if in real life, what you would think is basically you need to have some time here before you actually begin programming, to do things like designing to do things like creating the environments, etc. And that is where the content That offspring zero comes comes into play fever. So that's kind of before any of you know the spreads began if you will. So spread zero water spread zero give us basically a sprint during sprint zero, we will have a complete prioritization of the feature stories along with estimates if you will in the product backlog.

We will also use this sprint we to set up all the different programming environments development, testing, staging, you know, production What have you people, also you're doing a high level architectural design. So remember, you don't want to over plan in Agile but still you should do an over all design so you're not kind of doing design. You know, every time you're doing a sprint in a what you're doing is basically this is it. This is a high level design, if you will at the the You take on a sprint, you will go through more detailed design at that point for the stories if you have that, that will be kind of in the, in the realm or in the in the skeletal structure of the initial design the overall design that you've done, if you will. So that's kind of where you do the overall architectural design in sprint zero if you go and then also you can you do release planning, so you basically figure out okay, based on this, the product backlog the estimate of how long what effort it's going to be for being each of the stories and how important those stories are.

You basically work with the product owner to figure out what should be what are the minimum number of stories in that need to be in the first release the needs meaning, you know, where you can basically, either package it and be At least not deploying it in production. You basically say okay, this is my first phase is done and then kind of move on to the next phase if you will. So that's kind of, you know, is determined during sprint zero. So you figured out you know, what's part of your needs. This is it's interesting. It's it's important to understand that basically sprint zero does not have to confirm with the duration requirements of the regular sprint so for you all so if you remember from the life cycle that is the Sprint's are usually two to four weeks long, and typically more typically two weeks long if you go sprint zero, on the other hand, does not have to comply with a two week duration, if you will.

So you It depends on you know how long you've determined that basically, it's going to take to set up the environments and to go through these these processes. You still want to Do it as quickly as possible, but it doesn't have to comply with a two week two to four weeks rule if you can get it done sooner etc people remember the other thing is once you have made a determination whatever the duration of the Sprint's are going to be, so if they are two weeks long for example, they are going to be all the the sprints after the first sprint or sprint one is loaded afterwards. Sprint one sprint to sprint three sprint four etc. all would have the same amount of days if you will or amount of weeks if you will, same amount of duration. So if you determine that your Sprint's are going to be two weeks long then each sprint is going to be two weeks now if you determine your Sprint's are going to be three weeks long then each sprint is going to be three weeks now the Sprint's are equal in duration, but sprint zero does not have to comply with That if you will.

So that's kind of about from zero. Let's look at an agile release. So an agile release has these falling sprints if you will. So sprint zero if you will, as we talked about already that you know, that's our planning sprint. And then after you've spent zero you basically have on your different strengths and those are part of the, the needs of you. So once the sprint whatever and if you will is complete once all the stories that you want it to be in the first release or in this release are complete, that's when you're going to start your sprint and then you're going to get into their production deployment etc, if you will.

So release plan preliminary assign a story to sprint, so the best practice is initially when you during sprint zero it's a good idea to have you know, once you've determined that these are the Minimal studies that need to be making it to the sprint, sorry, making it to the release. What you do is you try to initially assign kind of what sprint number these are going to be in sprint one sprint to sprint three sprint four. This does not have to be so you know it's not written on stone if you will, once you you know, it's not like you can't change it later on during the Agile process. That is something that you put in sprint two, you can't move it to sprint three or sprint one. This is just to give you some idea that high level how you're going to be working on this product if you go as you proceed during your coding and all the things you will see how your velocity is how fast you're recording how many points stories you can put in each, you know, the different sprints and etc, and you're going to make changes to that as you go through, if you even you're going to, you may be making changes to the number of stories that initially you determined that you know are going to be part of release and this press release or this release, if you will, you there may be some additional stories that were not thought of when you start at sprint one, they that may get added to the product backlog because remember, the product backlog is a dynamic document.

And as you add those, you know, the prioritization and estimations and all those things are done and then a determination is made that you know, these are going to be part of this release or if it's going to be subsequent release, and if it is going to be part of this release, should you be, you know, deferring one of the original stories that you wanted part of this release to a future release, etc. So, so this is just to give you some structure, there where we are then we are starting this if you go estimation and end goal of how many sprints are estimated for the release. So, again release plan during the release and you basically estimate an end goal how many Sprint's if you will, and then understand this also that a project can have multiple releases, releases are basically like phases. Now, and another important thing to note is that not all releases have to be rolled out in production.

So, there may be a phase or the needs that you complete and then you do not roll it out into production and you move to the next release, if you will, typically, you will be rolling thing releases out into production, but there is not a hard and fast rule that all the releases have to be in production. As soon as they are done, you may start working on on the next release without moving the previous release into production. And after that next year needs us then you may move all of that together in production, if you will. So, That's kind of a high level on release plan on sprint zero. Hopefully this gives you an idea. These are all kind of, you know for providing a general idea as far as you know the overall structure of off of what the goal is the what the big goal is if you will, and and this should give you some idea from a timing perspective as well as you assign stories to sprints initially that should give you an idea that you know if your strength is two weeks on, how many you know, based on you know, the number of Sprint's you have assigned to the stories, you can get, get an idea that you know how long it will take to have this product in in actual production.

And lastly, something just to put an emphasis on if you will, is Don't over plan, just plan enough. That's kind of the motto of agile, that you know even though we are doing high level planning, during release plans, etc, understanding you know, Scrum zero, if you will, to understand, you know, the stories that are, you know, going to be part of release potentially part part of the this release, and also doing a high level architectural design in all those things, if you if you will, you should not be over planning, you should not be detailing out the design and all the things because remember, agile is there for a reason, right? To give you flexibility, that you may be changing it so you don't spend a lot of time just give enough structure to it. Before you begin your first pen.