Dealing with uncompleted tasks at the end of a sprint in Azure DevOps

Context

Whether working in project mode or in a “Service Center” style integration team, it very often happens that the end of a sprint is reached with some tasks incomplete.

According to the Agile methodology and its various frameworks (Scrum being the most popular), such situations are obviously to be avoided as much as possible.

However, we all know that our job is all about adapting to various changes, sometimes even mid-sprint.

New high priority requests, the dropping of requirements or assigning a lower priority and so on are par for the course in integration work.

We have been using Azure DevOps (the new name for VSTS) for several years now and we generally organize our teams and projects with the Agile methodology. Hence, we now have enough experience to step back and note the following:

“Agile methodology (and by extension the Azure DevOps system) needs to adapt to our organization, not the other way round.”

Taking this observation as the start point, how can incomplete tasks be better managed in Azure DevOps at the end of a sprint?

Dealing with sprint splitting

What we can call “sprint splitting” can be done manually, but we strongly recommend putting a procedure in place.

Many aspects can be automated, or made far easier, by the TFS Excel (and consequently Access) plugin. These aspects will form the subject of another article.

Let’s cut to the chase. The screen image below shows the backlog at the end of sprint 1.

It can be clearly seen that tasks 2, 3 and 4 are not complete.

Shifting the product backlog items from sprint 1 to sprint 2 is most definitely not the answer.

In so doing, the effort applied to the velocity for sprint 1 will be shifted to the effort in sprint 2. For example, take US1 where the estimated effort is 13. Here, 31 hours have already been completed, leaving just 7. If you shift this whole user story to the following sprint, the velocity for sprint 1 will no longer accurately represent the effort accomplished for the current sprint. In addition, the effort of 13 that will be applied to sprint 2 will no longer really mean much, as very few hours will actually remain.

Procedure

The following shows how sprint splitting is handled:

1. Duplicate the incomplete product backlog items (or user stories) and allocate them to the next sprint as shown below:

When duplicating items, remember to include existing links (see below):

As can be seen, we have renamed the user stories for the sake of greater clarity.

2. Update the effort on the original product backlog item (with help from the development team). It is possible to add effort onto the new user story immediately. However, we prefer to leave it empty for the time being, and evaluate it later, during the sprint planning stage.

3. Identify tasks not yet started, and carry them forward onto the next sprint.

In our example, only task 3 is affected.

4. Identify tasks that are in progress, close them and duplicate them, carrying forward the remaining work figure onto the following sprint.

In our example, this concerns tasks 2 and 4.

5. Close the user stories in sprint 1.

Recap

As you can see, this job could quickly become tedious if you have a large number of incomplete tasks. Hence you are encouraged to automate as much of the process as possible.

Despite this somewhat tedious aspect, you will see that there are many benefits to adopting this approach:

• readability;
• the links between various items are maintained, even from one sprint to another;
• accurate estimates for user stories (or product backlog items);
• consistent monitoring and reporting;
• etc.

To close this article, an image of the backlog before and after the “sprint splitting” is shown below:

Before:

After :