In this lesson we're going to be talking about agile sprint. So far we have talked about things around as our sprint. We talked about the product backlog and from the product backlog. The sprint backlog we've talked about the different ceremonies that happen around sprint, the sprint planning the daily Scrum, the retrospective, the demo, we've also talked about sprint zero and release planning. Now we're actually going to get into the sprint and see what all is happening in in during the sprint. So we're going to be looking inside the hood, if you will.

So, at a high level, we start with the product backlog. From the product backlog. We get the stories and from the stories we create spreads The sprints we create releases so multiple Sprint's basically create a product release and that basically gives us a product. So that's kind of in a nutshell what is happening now we're going to be looking at this card which is the sprint. So as as as we have talked before as well that it's typically two to four weeks in length. Important thing about sprint is the length of sprint is constant for each project.

So if we have decided that the sprint is gonna be two weeks long, each of the project sprint is going to be two weeks long except strand zero as we have talked about before sprint zero is an art sprint which is used for planning etc. If we for example, said that the Sprint's are going to be three weeks long, then each of the sprint after sprint zero are going to be constant duration of three weeks, if you will. So that's kind of Something that is very important to keep in mind. No changes to this sprint stories are allowed during the sprint. This is based on the scrum methodology or stamping framework. In some other frameworks like XP, they give you the option of swapping stories if they have equal endpoints.

If there needs to be a change made daily Scrum and sprint burndown charts, we'll talk about burndown charts in a future lesson. But we have the daily Scrum ceremony that we talked about in one of the previous lessons. Every day we have any meeting and answering three questions. What was done yesterday, what was his plan today, and if there are any blocks, any issues that is, so that's kind of in a nutshell, for an agile sprint. We talked about that the Agile sprint is constant innovation throughout the project. It has constant scope.

So basically whatever studies that you pick before the sprint for for that sprint is the scope for the sprint, that's part of the sprint backlog. Now, Sprint's can have variable points so in other words, maybe you pick 10 stories for the sprint that, you know, add up to say 30 points for sprint one. The next one does not have to have the same number of points you can have different number of points in different spreads. So net next friend for example, you pick nine stories, and they add up to say 28 points. And you can do that. So there's the number of points during the sprints do not have to be constantly in other words, each sprint can have different number of points.

Now we learn about the concept of sprint velocity. What you try to do is basically look at how fast how many number of points your team is accomplishing. And based on that, you will, you know, try to forecast the next sprint set, you know, give them as many stories as they can handle as they can complete during the sprint. Beginning of the sprint, we talked about this before, we would like to have test cases ready for this for stories. So this is a concept of TDD or test driven development where the test cases are there for the developers already. So as they are coding the software, they can actually run these test cases to make sure that they are coding perspex team commits to stories in sprint planning.

So those are the center mini definitely talks about the sprint planning ceremony. And then at the end of the sprint, we have the demo and retrospective retrospection. We also the end during the sprint we talked about another set of mini which is the scrum which is a daily Scrum that is happening, answering the three questions as we just talked about in the last slide, what was completed what was accomplished yesterday What is planned for today and if there are any glossary issues. So going to the next one, a typical sprint is going to have these different items that are getting completed during the sprint. So, we have we create, we try to keep ahead of our on our test cases, we try to create an update our test cases for the next trend initially. So this is a sprint that we are going to be starting the trying to make sure that the test cases for the sprint are completed.

And if there are any updates that need to be made to the strength before the sprint starts. And then we during the sprint we have at design, designing the stories that we have collected for the sprint. We do the development. We do peer code review of the code, we do your testing, we do system integration, testing as well as user Acceptance Testing. And then finally we do the demo of the splint and then the retrospection meeting are setting money off the screen. So those these are the different things that we go through.

During this this pain. Make sure that the first before the sprint starts make sure that the test cases are the updated are up to date. During the sprint, we design for the stories we call the stories we do a peer code review, then we do testing the different types of testing unit testing. So testing you will be testing the demo and the retrospection. Here's a typical or just kind of an example of a sprain. So, say that we read zero percent 20% is how much project is completed or how much the release is complete.

So at this point 20% of the release is complete at this point 40% and so on at the end of the fifth sprint, there are five Sprint's here and 100% of the Release is complete this is again just an example, red is showing us Is this the blue as you can see is sprint one, the next one is sprint two etc. So, in this particular example there were 20 points accomplished completed during sprint 125 during sprint 230 during sprint three etc. So, as you can see that the number of points accomplished during the sprint do not have to be constant, they can be variable, the duration of the Sprint's on the other hand have to be the same if you vote so this just again is giving the percentage of release completed. This is not it doesn't have anything to do with the duration. And but this is just kind of talking about you know what percentage of the release is completed at this point of view.

So, just again, this this graph is trying to emphasize that the sprint number of points in the sprint do not have to be constant in each sprint. They don't have to be the same in each sprint if you go they can be different like in this one cranky 45 etc. Another really important concept is the definition of done one of the things that we talked about in one of the previous lessons is we need to have common vocabulary and we one of the most important words is done. When do we when do we say a story is completed or a study is done. So we need to be agreed upon the definition of done before the project starts. What then typically means is the story is designed it's coded.

The score reviewed and tested all the different tests are completed including the unit unit testing, the system integration testing, and user acceptance testing are completed. So those are the four items typically that constitute a study to be complete are Done. Again, what all will be done during the sprint. So this is kind of a different way of showing the graphical, you have the test cases before the sprint, you have updated the tasks in sprint backlog every day. So when you do go through your Scrum meetings, you are making sure that you're updating how much the different tasks are completed for each of the stories. Remember, during the sprint planning, we have picked the stories and we have divided the stories into what our tasks or work packages need to be done in order to complete that story.

So what you're doing every day what the Scrum Master is doing every day is keeping a track off, how much of those tasks or what band practices are getting completed every day. And we've talked about the concept of burndown charts later in a different lesson. And you will see how that kind of helps you know to determine how The team is doing if the team is bigger than nine people then you have Scrum of scrums again because we have talked about this concept in a previous lesson. When we went to this agile ceremonies, we do the demo and retrospection at the end of the sprint. Also, if there's a new story that gets added because you know the customer after looking at the demo of the programmers after doing some coding on the same day, they they presented this to the customer, the product owner, and they think that this this new story should be added.

You can have a repaired reprioritization of backlog on another instance would be if there is a story that was originally added to be done in the sprint, but was not completed. So it's that event it's not completed it goes back to the product backlog. And then you have to reprioritize the product backlog to see how important Those are the stories are if they are the same priority, or if some priorities change, and then assign it to whatever sprint is that the stories need to be assigned to. As a best practice, you need to be doing the daily code check in. You're trying, you're doing a continuous build and integration. So you're not finding at the end of this are close to the end of the sprint that you know, there are any issues and with integration.

Also, you're doing code review, once any story is completed. You're testing for the story against the test is once it's done. So what again, this is the concept of TDD test driven, test driven development, where you making sure that the programmer is not assuming things are the QA person is not assuming things, but actually testing. They have a test script, and they once the students complete they can test it against the test prep and make sure that it complies with this test. Step two Complete that loop between the product owner and in the quarter. Here's how a change is handled attended requirements is handled in sprint.

We talked about this a little bit in the previous slide is there any changes, whether it be the product owner saying that any of the team member talking to the product owner and product owner adding this to the product backlog or if there was a study that was not completed that was planned to be completed in a particular sprint that was not completed, it goes back to the backlog, and then you do go through a reprioritization estimation, you do make sure that the test cases are up to date for that if this is a new story, then new test cases need to be done. And then you review the release plan to see if this is affecting the release plan in any way. So these are the different items that are part of a sprint. I tried to grow To ensure these to you from different angles and hopefully this this makes sense.

These are the items that need to be completed in order for a story to be considered done or complete.