Step-by-Step Closing of A Sprint with MS Project Agile

Takeaway: A Sprint is considered to be a mini-project within a Scrum project. Like every project has to be closed, a Sprint, also has to be closed. However, many Agile practitioners do not follow this practice. In this article, we will take a scenario for Sprint in a Scrum project and follow the steps needed to close a Sprint Project.

We will begin with a scenario for a project, proceed with various steps to close the Sprint within a release, and learn a variety of functionalities available in MS Project 2019 Agile. Then, I will demonstrate the closing steps. Keep in mind that closing a Sprint differs significantly compared to the closing of a traditional project with MS Project.

Our Project Scenario *** UPDATED ***

In our project, there are a number of releases, and each release has a number of Sprints. The decomposition pattern can be in a variety of ways, such as:

• Product > Epics > Features > Iterations > User Stories
• Product > Iterations > User Stories
• Product > Releases > Iterations > Features
• Product > Releases > Iterations > User Stories 
• Product > Features > Releases > Iterations > User Stories
• Product > Features > Epics > Iteration > User Stories, among many others

In our case, the pattern will be: Product Backlog > Project > Releases > Sprint/Iteration > Features > Tasks. This is to maintain consistency with my earlier piece on Agile release planning. If you are working with any other decomposition pattern, you can still follow the steps laid out in the below video [duration: 4m:55s]. I’ve prepared the video in support of this article, so that readers will have understanding of the scenario. For the best experience, you may want to go full-screen HD and plug-in your earphones.

When using MS Project with its Agile features, the following depiction is visible in the Sprint Planning Sheet view. This view shows multiple releases within a project and multiple Sprints in every release. 

You may be wondering about the empty Resource Names column. It’s empty because resources are assigned to tasks, not the Releases, Sprints, or features. The features (or stories) will be summary tasks because they are finally broken down to tasks, to which resources will be assigned.

Specifically, for Sprint 1, which is under consideration in our case, we have the following view using the Current Sprint Planning Sheet view. 

In the above figure, I’ve applied a custom grouping: Sprint and Features. This enables a better visualization. I’ve also added the % Complete in-built column.

Looking at the above figure:

• Sprint 1 has three features: ‘Login to the online trading system’ (100% complete), ‘Create a new user’ (100% complete) and ‘Edit an existing user’ (40% complete).
• The feature of ‘Edit an existing user’ has a number of incomplete tasks, as the Scrum team could not complete these tasks.
• The Daily Scrum events are not all complete. Hence, the summary task of ‘Daily Scrum’ is shown to be 88% complete.

Set the Status Date *** NEW ***

This update is as on the final day of the Sprint, i.e., September 23, 2022. The status date can be set by going to the Project tab > Properties group > Project Information dialog box and setting the ‘Status date:’ field.

You can also set the date by selecting ‘Status Date: command’ under the Status group of the Project tab. Some practitioners find this way to be quicker.

As you complete the task items, or move the items across the workflow states, it’s likely that some of the items will remain in a Not-Done, or unfinished state. Items with unfinished status can be tracked in ‘Sprint Backlog,’ ‘Next Up,’ ‘In Progress,’ or any other custom state or column you define. This situation leads us to our next step.

Move the Incomplete Items to Next Sprint

The tasks or items which are planned for the current Sprint, but could not be completed, are usually moved to the next Sprint. This can be done in the Current Sprint Board view. 

As shown above, we have a number of tasks under the feature, ‘Edit an existing user,’ in the Sprint Backlog. All these incomplete tasks should be moved to the next Sprint by selecting the task item and choosing the ‘Move to Next Sprint’ command after right-clicking. This has to be done for all incomplete tasks.

Check the Daily Scrums

Incomplete Daily Scrum events need to be closed. Otherwise, they will remain on the Board and Sheet views, which may create problems while managing and tracking the next Sprint.

For a two-week Sprint, there will be a number of Daily Scrums, as explained in the article, Building A Sprint Backlog with All Scrum Events in MS Project Agile. To complete these events, enable the filter option in the Current Sprint Planning Board view.

The filter option is available at the far-right part of the board view. Select the ‘Daily Scrum’ summary task to display all the Daily Scrum events, as shown below. 

With the filter applied, the incomplete Daily Scrum events will be visible in the board view. Select the incomplete ones and simply move them across to the Done state.

Complete All Sprint Events

Other than the Daily Scrum event, there are events such as Sprint Planning, Sprint Review, and Sprint Retrospective. The Sprint Planning event happens on the first day of the Sprint. By this time, the event should have been closed. If it’s not done already, you must close this event’s associated task.

However, the last two events of Review and Retrospective happen on the final day of the Sprint. It’s easy to forget to close these two events as the current Sprints ends, and the next immediately starts.

These last two events can be closed in the Current Sprint Board view. 

As shown, we now have only two tasks in the Sprint Backlog workflow state: the events of Sprint Review and Sprint Retrospective, which are highlighted. These events can be closed by dragging and dropping them into the Done column.

Ensure the Sprint’s Completed Features

At this stage, all tasks have been closed or have been moved into the next Sprint, if they remain incomplete. We have also closed various Sprint events. Now, it’s a good idea to review the features with the associated task to ensure that the percent completion is 100% at the overall Sprint level.

This will look like the figure below, in the Current Sprint Sheet view. At the highest level – after applying the grouping for the Sprint – we have 100% completion for the entire Sprint. 

Note that for the ‘Edit an existing user’ feature,’ we have only one completed task: ‘Design and develop.’ Remaining tasks have been moved into the next Sprint, which in our case is Sprint 2. This synchronizes with the previous step and confirms that it is complete.

• After completing this step, you may have the following questions:
• Where can one see the tasks (associated with features) moved into the next Sprint?
• Are the tasks properly placed as part of the next Sprint?
• Are the tasks properly associated with the Release?
• Will the workflow state (anything other than Done state) be preserved when moved into another Sprint and Release?

To answer the above questions, we will move to the next step.

Review the Sprints within a Release

The Sprint completion within a release can be confirmed with the Sprint Planning Sheet and Sprint Planning Board views. In MS Project, when a Sprint gets completed, both the Sprint and Sprint work items are removed from these Sheet and Board views. Though it may be confusing initially, in fact, it’s quite logical: because the Sprint has been completed!

For our case, the current release plan after Sprint 1’s completion is shown below in the Sprint Planning Sheet view. This not only ensures that the concerned Sprint (Sprint 1) has been completed but also ensures its reflection in the release plan. 

As shown:

• Sprint 1 items are complete. Hence, the Sprint and its associated items are not reflected in the Sprint Planning Sheet view. However, you can change the built-in filter to display the items.
• The tasks under ‘Edit an existing user’ feature are now part of Sprint 2. These items are highlighted under the Task Summary Name column.
• The other feature items such as ‘Buy a stock’ and ‘Sell a stock” were previously planned to be part of Sprint 2, and they are highlighted.
• The Feature flag is showing as enabled for both of the above two feature work items, whereas the flag is disabled for the task items moved from Sprint 1.
• All the tasks are not only properly associated with the next Sprint (Sprint 2) but also with the release (Release 1).

You can also cross-verify this in the Sprint Planning Board view, which is shown below. The Sprint 1 column in this view is now completely empty. 

In MSP, it is by design that a completed Sprint is not available in the Spring Planning Board. This is because in both the Sprint Planning Board and Sprint Planning Sheet views, the filter applied is Sprint Planning Filter.

If you want to see all the Sprints plus all the associated features and tasks with % completion, you can customize the filter and apply it to the view or create another custom view. The video below explains this process in more detail.

Plot the Velocity Histogram *** NEW ***

Another practice that is followed by Agile practitioners using MS Project is to build a Velocity Histogram. The velocity histogram is one of the most used reports used by Scrum Masters, Product Owners or Agile Project Managers – the last one considering Hybrid Agile project.

Velocity histogram is a vertical bar chart with a pair of bars showing velocity metrics over a series of Sprints. The first part of the pair is usually the planned velocity, whereas the second part of the pair is the actual velocity.  When plotted together, one can quickly infer and interpret the data, which can also be used for forecasting. A sample velocity histogram is shown below. 

You can learn more about building the velocity histogram in this article.

Demonstration, Review and Analysis

We covered the major steps to close a Sprint for a Scrum project. Now we will demonstrate, review, and analyze the steps that we have learned so far. The below video [duration: 6m: 21s] is taken from my course, Mastering MS Project 2019 Agile, and explains how to close a Sprint in more detail.

Conclusion *** UPDATED ***

Closing a Sprint is an important step that should be done diligently by the Agile Project Manager or the Scrum Master.

Leaving the tasks and events open, directly updating the % Complete column field for the tasks without moving the tasks across the board, or updating the previous Sprint’s tasks in the current Sprint creates confusion for your team members. It also results in wrong reports, such as the Velocity Report, Burndown Chart, or Burnup Chart. More importantly, your plan will no longer be correct.

It’s also pertinent to note that only the features which are completed will count towards velocity, not the ones which are partially complete. Even one task item remaining incomplete should not count toward velocity. If you are using stories and story points to estimate for planned and actual velocity, then your project plan should have the proper velocity calculation in MS Project.

Everything you need to close a Sprint for a Scrum Project is available at your fingertips with MS Project. Go ahead and close your Sprint rapidly and elegantly…and sprint for the next Sprint!

--

This article was first published by MPUG.com on 11th October, 2022. This is an updated version.

References

[1] Online Course: Mastering MS Project 2019 Agile (Scrum, Kanban and Scrumban), by Satya Narayan Dash

[2] Certification Course: Certified Hybrid-Agile Master Professional (CHAMP) with MS Project, by Satya Narayan Dash