After watching this video, you'll be able to close out the sprint on the Kanban board, describe how to handle unfinished stories, and prepare for your next sprint. I want to talk about the end of sprint activities. What do you do at the end of a sprint after all the meetings are done? Well, you want to take anything that's in the done column and move it to closed. You might have done that during the sprint review, but if you didn't, now is the time to move all of the done items into the closed column. You also want to close out the current milestone. If you're using sprints in the new ZenHub, they may close themselves out based on the end date, but a regular milestone in GitHub will not close itself until you close it just in case you run late. So, you're in control of closing it. And so, you should close out that milestone, so you get credit for velocity on your velocity charts. You then want to create a new sprint milestone. Now you might leave this until the next sprint planning meeting, and that's okay, but just understand you close out one milestone you're going to have to create a new milestone for the next sprint. And then you want to adjust any unfinished work. So, what do I mean about unfinished work? Well, there's untouched stories. What about stories that haven't been worked on? They're in the sprint backlog and no one got to them, right? So, you can move those to the top of the product backlog. Some people move them to the next sprint. I like to resist the urge of just moving them into the next sprint because, what if they're not the top priority anymore? What if, we didn't get to those stories but in the middle of the sprint a new, uh, feature was requested, that is our new top priority. So, I don't make any assumptions that just because we were working on it the last sprint, we ought to be working on the next sprint if it wasn't finished. And so, I like to take them and move them to the top of the product backlog. If you do, remember to unassign them from the sprint milestone, right, you don't want to have those dangling stories in the sprint milestone. Take them out of the milestone, move them back to the top of the product backlog. How about unfinished stories? These are stories that people did get to, but they didn't finish. Very important for this, is don't move the unfinished stories into the next sprint. Again, you're going to mess up your velocity. Somebody spent time working on half a story and so what you should do is you could determine, uh, you know, was the sizing wrong, uh, if it was, you can adjust it. If it wasn't wrong, okay, it was an eight pointer, I only got to do four points of it, then adjust the size down to four and then write a new story because you want to keep your velocity accurate. Write a new story for the... put it in the product backlog, that's the other four points. But give the developer credit and give the team credit for working on those four story points. So, you never want to simply move them into the next sprint. You want to take them and close them in this sprint, so you get credit for the velocity, and then if you need to, write a story for the next sprint with maybe more story points or half of the story points from the previous one. The other thing you want to do is adjust the description, right? You might want to say that this thing is unfinished. You might want to create an unfinished label, you know, so that you can tell that it was closed but it wasn't closed and completed, maybe, a not completed label but the idea is that you definitely want to identify in some way that this is a half-finished story. But you're closing it because you're closing out the sprint and the work was done in that sprint even though it was only half of the work. Then you write a new story for the remaining work, right? So whatever work is left and maybe it's the remaining story points or maybe it's even more story points because it was bigger than we thought, whatever it is, you write that story, put it in the product backlog, and then we could decide whether we're going to do it or not in the next sprint. Or maybe because it's half done, you're guaranteed, you know, that you want to do it in the next sprint, uh, then you might want to move it to the next sprint, assuming you've already created that sprint milestone. And then you want to remain, if you do write a new story, assign the remaining story points to that new story. Again, what we're trying to do is keep the velocity accurate. We want to get credit for the number of story points executed in a sprint regardless of whether the story was finished or not so that we know that our velocity is accurate in the next sprint. We know how many story points we can take on to execute. So, getting ready for the next sprint, all the current stories should be assigned to, uh, the current sprint should be closed, right? Anything in the current sprint, you want to close that. All the unfinished stories, they get reassigned. So, you've handled all the stories are unfinished… close them, maybe write new stories for the rest to finish them and then any of the sprint milestone is closed, any stories that were in that sprint milestone get taken out of it, put in the product backlog, uh, and then maybe a new sprint milestone is created either at the end of the sprint or at the beginning of the next sprint. In this video, you learned that it is important to give developers credit for unfinished stories, unfinished stories should be split into new stories to complete the work in the next sprint, each sprint milestone should be closed when completed to reflect the velocity of the sprint, and you should create a new milestone for the next sprint.
