TRANSCRIPT

Welcome to Part 4 of the Mastering Azure DevOps for Project and Program Managers video series.

In this video, we will demonstrate how to plan the work of a development team using sprints.

By the end of the last video we had a backlog of work items for our development team to migrate an application to the Azure cloud.

Before adding stories to sprints, the team can work with the product owner to prioritize the user stories.

This can be done from the stories backlog view. Open the view options and turn the parents slider to the off position so that only user stories are visible.

Drag and drop the stories into the order they should be worked on in. If one story cannot be worked on before another is completed, be sure to account for that dependency in the prioritization.

Next we’ll define the project sprints. This can be done from the project configuration page. We recommend that all teams on a project use a common sprint definition.

Click the three dots to create our first sprint.

Come up with a sprint naming convention that you will use in all your project areas, perhaps something like this. Choose the dates when the sprint will begin and end, and then click save and close to create the sprint.

Repeat these steps to create as many sprints as necessary.

Now that our project sprints have been created, we can add them to the field operation teams work plan from the team configuration page. Open the iterations page, then click the select iterations button, and choose the project iterations that the field operations team will be performing work during.

Now lets build our first sprint by adding stories to it. Stories can be added to sprints from the backlog view. Adding stories to sprints is commonly done during sprint planning, when the team will commit to the items that will be delivered.

To see an estimate of how many stories can be handled during a sprint, turn the forecasting slider to the on position.

Realistically estimate the number of points that can be delivered in a typical sprint while providing for good work-life balance.

ADO draws a forecasting line suggesting which stories could be in the first sprint.

You’ll also notice that based on a team capacity of ten points per sprint, that the team will need more than a second sprint to complete the entire backlog.

Additional project sprints can be added to the teams work plan from the planning pane.

Select new sprint and ADO automatically grabs the next project sprint. Click create, to add the sprint to the teams work plan.

An additional forecasting line shows that the last two user stories can fit in the third sprint.

Please note, this does not actually add stories to a sprint, it’s only an aid to help the planning process.

To add a user story to a sprint, drag and drop the story into the appropriate sprint in the planning pane.

The tasks are automatically added to the sprint.

Stories and their tasks can also be added to a sprint by clicking on the three dots next to the user story title and selecting move to iteration.

Now that we’ve added items to our first sprint, let's check out the sprint board.

Here we see the two stories we added to the sprint and their tasks.

To help prevent overloading a sprint, we can use the capacity management tool in ADO.

This shows the number of hours per day that each team member can work on the project in a given sprint. Since there is commonly unplanned work, we don't want to estimate at 100% capacity, and encourage leaving two hours in reserve.

The team days off feature can be used to record holidays and other non-working days. Personal time off for individual team members can be recorded here as well.

When using this tool, team member capacity needs to be set for each sprint. Let’s select the next sprint and copy our capacity data from sprint one to sprint two. Click the three dots, select copy from last sprint, and then click save.

Let’s see how the teams capacity compares to the work put into sprint one.

We can see this from the work details side pane. This shows that none of the team members have more work assigned to them than they can handle in the sprint.

This value of 24 is based on the remaining hours field. We can see this if we change the value in one of the tasks.

Notice how the value changed from 24 to 16. Let’s put it back to 24.

In the backlog view, we can see our planning results.

The first sprint is noted as having 9 working days since we marked May 9th as a day the entire team has off.

We also see two stories worth ten points and six tasks are in the first sprint.

In many projects, these types of planning activities will be performed repeatedly over time and form the basis of your project roadmap.

This concludes the demo. In our next video we will see how the work demonstrated in our first four videos comes together in the creation of an enterprise roadmap using Portfolio++

iTrellis, a technology solutions consulting firm specializing in custom software development and design, Azure DevOps, and data analytics. Dedicated to understanding clients business strategy, aligning appropriately skilled consultants, and delivering projects while maintaining work-life balance. Learn more at iTrellis.com