How do you close out a Scrum Sprint in Azure Boards? Especially, what should you do with partially completed user stories and tasks?

Question

I am new to Azure Boards and finding it can be very confusing when it comes to scrum sprint ends and planning the next sprint. What should you do with user stories and their tasks that are only partially completed at the end of the sprint? Stories and tasks that were started but not completed within the sprint.

What is the correct way to manage partially done work at the end so that sprint metrics, velocity etc, are correctly accounted for?

I am finding it difficult to find guidance for sprint planning in Azure Boards that explains what to do with these incomplete work items. If you know of guidance that explains this, include links to it.

Answer 1

What should you do with user stories and their tasks that are only partially completed at the end of the sprint?

They return to the backlog. On your next sprint's planning, if the stories are still relevant, you will re-estimate them and plan them for the sprint you are about to start. All the unfinished stories in the current sprint account for zero to the sprint's velocity.

There are teams that split the work into two and account for half the story points in the current sprint and half for the next one, but I believe that's usually a bad idea and it's something teams do if they feel pressured to keep high some velocity metrics. If unfinished work moves to the backlog and you count zero for that work in the velocity, then velocity will take a dip, and teams don't want to show that. But like I said, that's a bad idea.

Velocity is a metric that you measure so that you have some historical data on past work to make forecasts for future work. The point of the sprint is not to keep velocity high (which is a delusional way upper management thinks the team is productive) but to reach the sprint goal and have a working increment. That is the real measure of progress: real working software.

When you split the story and keep some of it in the current sprint, you don't have working software for the story you split, only partially working. The increment has a commitment attached to it which is the definition of done. Basically, with the story you split you are breaking the definition of done. You look the other way basically, because you want to salvage some velocity for nice reports instead of for what's important: working software. This opens up a door for doing it again in the future when it's convenient. Not good.

Work is either done at the end of the sprint or it isn't. If it's done it counts, if it's not then it gets reconsidered next sprint and accounts for any metrics in that next sprint, not the current one. Velocity will tend to level itself no matter how you choose to do things but at least when you consider only done work it is a more realistic value and a much better source of historical data to make future forecasts.

Answer 2

In our project we know upfront that we will not able to complete all tasks of a user story in single Sprint hence we always ensure that only task can be completed is assigned in current Sprint and other tasks are assigned to next sprint.

We ensure that each PBI is also marked as Done only in the Sprint in which all its tasks are completed.

I agree with Bogdan; splitting a function and dividing PBI and marking as partially complete is not the right approach as it really doesn't create value or incrementally working software. Velocity really does not define team productivity rather it should be used as a metric only for planning future Sprints.

Answer 3

Once all the tasks are set to "Done" by developers for the "user story", Set the user story to verified. If tasks are pending, it can be re-estimated quickly and taken up for next sprint as a spill over tasks (in presence of PO). Later, stories of previous sprint can be set to verified, as tasks are moved to current sprint and efforts are re-estimated.