One of the key artifacts in a Scrum Project is the Sprint Backlog, with others being the Product Backlog and (Product) Increment. The Sprint Backlog is prepared during the Sprint Planning event, and it’s used throughout the Sprint. The Sprint Backlog, not only takes the product backlog items from the top of the Product Backlog, but can also have individual tasks and other non-feature tasks associated with it.
Some project management practitioners think that the MS Project software is not a suitable tool for managing Scrum projects or Agile projects. However, it’s not the case. In fact, everything that you want to do in a Scrum project can be done with MS Project using its in-built Agile features.
In this article, we will explore how to create a Sprint Backlog, along with its content items such as features. I will demonstrate how to break down features into tasks. Towards the end of this article, I’ll demonstrate with a video using the MS Project 2019 Sprint feature available in MS Project Online Desktop Client.
The Product Backlog
The Product Backlog (PB) has all the features that you want to deliver over the life cycle of a product. A set of work items are taken from the PB for every Sprint, which in itself is a short project. Before the start of the Sprint Planning event, the PB is ordered with the highest priority items at the top. You can prioritize the backlog items with various prioritization schemes.
An example Product Backlog is shown below in the Sprint Planning Board view with a number of feature items to be delivered for a Stock Trading System. You can go to this view from Sprint Tools > Sprints tab > Views group. Select the Sprint Planning Board command from Planning drop down menu.
example Product Backlog
Let’s look at the first three items for our upcoming Sprint, i.e. Sprint 1. As this PB is presented to the Scrum Team, the team decides to the take the top three items into the Sprint Backlog:
- Feature- 1: Login to the online trading system
- Feature- 2: Create a new user
- Feature- 3: Edit an existing user
To do this in MS Project, we have to drag and drop from the “No Sprint” board column to the “Sprint 1” column.
Dedicated Resources
In a Scrum Team, it’s a good practice to have team members who are 100% dedicated, including the Product Owner (PO) and the Scrum Master (SM). This results in less troublesome situations, the likes of which we have explored in a previous article, Lean-Agile Troubleshooting.
As the Scrum team decides what items are to be pulled into the upcoming Sprint, we need to have team members available. This is depicted below.
As you may have noticed, the team consists of the developers, the PO, and the SM. I’ve grouped them accordingly, which will help in further filtering, grouping, highlighting, and generating reports in MS Project.
The Sprint Backlog (First Cut)
As the team has decided on the feature items to be delivered for the upcoming Sprint -1, the first cut of our Sprint Backlog is ready. This can be seen in the Current Sprint Board view. You can go to this view from Sprint Tools > Sprints tab > Sprint group, and then select the Current Sprint Board command from Sprint drop down menu.
Our Current Sprint Board is for Sprint 1 and is as shown below. In it, we have four workflow states: Not Started, Next up, In Progress, and Done.
I’ve renamed the “Not Started” workflow state as “Sprint Backlog,” to clearly indicate that the items in this state are the backlogged items for this Sprint.
Add the Scrum Events
Now, we are going to add the Scrum events by switching to the Sprint Planning Sheet view. You can go to this view from Sprint Tools > Sprints tab > Views group. Select the Spring Planning Sheet command from the Planning drop down menu.
In this view, we will add the following Scrum events:
- Sprint Planning – A task
- Sprint Review – Also a task
- Sprint Retrospective – Also a task
- Daily Scrums – Recurring Tasks
As shown below, I’ve added the Sprint Planning, Sprint Review, and Sprint Retrospectives as tasks in the Sprint Backlog.
The “Board Status” column in the above view is now showing Sprint Backlog because we changed the workflow state (board column) name earlier. Also, remember to associate all the events with the current Sprint (Sprint 1).
Add the Daily Scrums
The slightly tricky part is the addition of the Daily Scrum events, which will be recurring. These can be added by going to the Task tab of the Ribbon and inserting a recurring task with the following entries:
Recurring Task in Daily Scrum
When you have this recurring task as part of the current Sprint Backlog, enter it just above the “Sprint Review” task. This is because this event happens after the Sprint Planning, but before the Sprint Review and Sprint Retrospective.
As you add the Daily Scrum events, the Current Sprint Sheet view will be populated with all the Daily Scrums for the current Sprint.
Sprint Planning Sheet
As you can see above, there are a number of Daily Scrum meetings. The Task Summary Name column in the view has been populated as “Daily Scrum.” This is how the Sprint Planning Sheet view is designed.
However, when you save this Sprint Planning Sheet view, then the Summary Task name of “Daily Scrum” will NOT be available! This confuses many, but it happens because this view of the Sprint Planning Sheet filters out the Summary Tasks and puts them under the Task Summary Name column.
Breakdown the Features into Tasks
One can continue planning in this Sprint Planning Sheet view. After all the name of the view itself tells this is the view in which you will plan for the Sprints.
However, we will switch to the Gantt Chart view (or Task Sheet view) to add the tasks under the three features we have selected. This shows you another way and also shows the tasks under the features as indented. In our case, all the three features taken for Sprint 1 will be Summary Tasks.
In the below Gantt Chart view, I’ve added two more columns, Sprint Start and Sprint Finish, which will help us to plan for the current Sprint.
As shown, the current Sprint now has the three features: all the Scrum events for this Sprint along with the Daily Scrum (as a summary task) and the duration assigned to the Daily Scrum meetings.
Next, from this view, we are going to break-down the features into tasks and assign the possible duration along with the Start and End dates for all the tasks.
This work also happens during the Sprint Planning event, as team members decide who will do what tasks. Remember, the Scrum team is self-organizing and self-managing.
For all the Summary Tasks (three features), we ’ll have these sub-tasks:
- Design and develop
- Implement UI
- Prepare test plans
- Execute test plans
- PO review
You can change the above task names as the team members discuss and break-down into tasks during the Sprint Planning meeting.
To add the tasks, you just have to right-click and insert the sub-tasks. Indent the tasks added to make the features display as Summary Tasks. Unlike the Sprint Planning Sheet view, in this view the Summary Tasks won’t be filtered out. This results in the following figure:
Now, we are going to look at the durations, as well as apply the resources to these tasks. In Agile projects, the Scrum Master (SM) doesn’t assign the tasks to team members. Rather, the team members decide who does what.
The job of the SM or Agile Project Manager (APM) is to facilitate and build the Sprint Plan (Sprint Backlog in MS Project) by taking the information from the team members and/or from a white board discussion meeting. After applying the resources, we will have the following view:
At this stage, it’s important to make the following notes for this Scrum project:
- The three features for our Sprint 1 are taken as Summary Tasks.
- Each feature has been broken down into multiple (sub)tasks.
- All four Scrum events are included as part of the plan with respective durations. For a two-week Sprint, I’ve applied the following durations:
- Sprint Planning = 4 hours (0.5 days)
- Sprint Review = 2 hours (0.25 days)
- Sprint Retrospective = 1.5 hours (0.25 days approx.)
- Daily Scrum = 15 minutes
In addition, the planned duration, as well as the planned start and end dates, are there for all tasks under the feature items.
Resolve Overallocations
It’s possible that while applying the resources, there will be some overallocations. It’s natural, and the MS Project tool provides a large number of options to resolve overallocation. For example, in the above figure for this Scrum Project, we have overallocation notifications for Task ID – 1 (Sprint Planning) and Task ID – 3 (Design and Develop).
You can easily see and resolve the overallocations by splitting the view and bringing the Resource Graph view into the bottom pane.
This clearly shows the concerned team member (Eric S) is working 4 hours extra on the first day of the Sprint. You can also see the overallocation in the Resource Graph indicated by a red vertical bar. This matches with the horizontal bar in the Gantt Chart view above.
Because of the overlap between the Sprint Planning event and the task of Design and Develop, you can resolve this overallocation by adding a Finish to Start (FS) dependency between Task ID 1 and Task ID 3. The predecessor field is available by default in the Gantt Chart view above.
This dependency is logical because, only after the Sprint Planning is over, can the team members start working on the task items.
The Sprint Backlog (Final Cut)
Now we will go for the final cut of the Sprint Backlog and give ourselves finishing touches as needed.
For this purpose, I’ll first go to the Current Sprint Sheet view. You can go to this view from Sprint Tools > Sprints tab > Views group. Select the Current Sprint View command from Sprint drop down menu.
Like in the Sprint Planning Sheet view, the Current Sprint Sheet view does not show the Summary Tasks with their sub-tasks indented. Rather, the Summary Tasks (features, in our case) are moved into the Task Summary Name column in the Current Sprint Sheet view. This is highlighted above.
If you want to see it along with grouping under the Task Summary Name, simply create a new custom group and apply this grouping to visualize. It’s depicted below.
The Scrum events such as Sprint Planning, Sprint Review, and Sprint Retrospective are non-Summary tasks, whereas we have other groupings with respect to the Summary Tasks (features), such as “Create a new user” or “Edit an existing user.” These features have tasks under them.
Key Points – Working with A Scrum Project
Now let’s have a demonstration of the Sprint Backlog that we have created and review a few key points. They are explained in the video [duration: 7m 01s], which I’ve prepared in support of this article. The content of this has been taken from my new course, Mastering MS Project 2019 Agile. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.
These key points are important for any MS Project Agile practitioner, especially if you are moving from a traditional development mode to Agile.
Conclusion
Now our Sprint Backlog is ready, and the APM or SM can easily track easily the current Sprint Backlog, i.e., Current Sprint Board view in MS Project, as shown below:
In the above figure, I’ve customized the cards to include fields such as Task ID, Task Summary Name, Start Date, and Work. The customization command in MS Project is highlighted.
As you proceed with your Sprint, drag and drop the cards across the Board columns. If the work item is complete (i.e. dragged to Done), a tick mark will appear on the top right part of the card. In the above case, the Sprint Planning work is done and you have a tick mark for this work item. This is also explained in the above video.
I hope this article provides you with an in-depth understanding on how to prepare and proceed with a Sprint Backlog, one of the most important artifacts used in a Sprint.
Go on and start sprinting without any obstacles with MS Project!
References:
[1] NEW Online Course: Mastering MS Project 2019 Agile (Scrum and Kanban), by Satya Narayan Dash
[2] Online Course: MS Project Live Lessons, by Satya Narayan Dash
Bruce Carter III
Satya,
Thank you for providing a clear concise tutorial on building and managing a sprint backlog in MS Project. This is a very valuable reference. Most in our profession do not fully understand the scheduling capabilities of MS Project. Showing it applied to Agile was definitely needed.