Azure DevOps for Agile Projects (2024)

By: John Miner |Comments | Related: More > DevOps

Problem

If you are new to modern day development, you might think that the wordsAgile and Scrum are interchangeable concepts sincemany project managers refer to them during team discussions. However, thereis an important distinction between them.

Agile refers to a set of principles expressed in theAgile Manifesto. Collaboration, self-organization, and cross functionalityare some of the traits of an agile team. On the other hand,Scrum is a frame work used to implement agile development.

MicrosoftAzure DevOps is the next generation of Visual Studio Team Services in the cloud.This product combines scrum project management tools and software version controlinto one service.

How can we plan, track and execute tasks using Azure Dev Ops?

Solution

The Boards menu can be used by a Scrum master to create product backlogs andplan sprints. The Repository is a standard offering of the Git version controlsoftware. Visual Studio 2017 integrates nicely with the Repository you definedin your Azure DevOps project.

We just need to learn how to integrate (link) project planning with task execution.This includes creating code branches, linking project tasks to code branches, pullingand pushing code to/from the cloud, and merging code branches when work is complete.

Business Problem

Our boss has asked us to investigate how to execute an Agile Sprint using AzureDevOps. I will be continuing with the Adventure Works Data Warehouse samplethat I have been using for this series of articles.

Adding Team Members

Usually, there are between 5 and 9 people assigned to an agile team. Rightnow, the craftydba0785 DevOps account only has one team member.How can we add additional members to the team?

I am assuming that a team member or user account named Dilbertis already part of Azure Active Directory. The first step is to login intoAzure DevOps service. The image below shows the section of the menu namedorganizational settings which will allow you to add additionalusers.

We can use the search feature in the user's box to find our team membernamed Dilbert. If you have more than one project going on at the same time,we can assign him to additional projects at this time. For now, we will addDilbert to the advwrks4tips19 project as aproject contributor. Click the add button to complete thetask.

Now that we have two members on the team, we can start creating our project backlog.

Scrum Lifecycle

The customer or client approaches the software manager with a list of enhancementsthat they like to see in the next iteration of the software product. Thismanager will break down each of the enhancements into discrete tasks that the teamneeds to design, code and test. These tasks are called product backlog items(PBI).

During execution, the project manager will create a sprint and plan which itemscan be accomplished during the two-week period. The actual time period ofthe sprint depends on your organization.

These items will be assigned to the team members and work will begin during thesprint. Each day, team members review what has been accomplished yesterday,what is planned today and what blockers were encountered in a daily scrum.It is the responsibility of the Scrum master to make sure blockers are resolved.The actual length of the team meeting orstandupis keep to 15 minutes for productivity. Any issues that require more attentionare moved to a separate meeting with only required team members.

At the end of the sprint, a review and/or retrospective is used to see if thingscan be executed more efficiently or back log items have to be moved to the nextsprint. Hopefully, if all back-log items were completed and any dependencieswere fulfilled, the code repository will potentially have a shippable software releasewith an incremental change.

The above image shows the ideal way a sprint would be executed. Projectsprints are executed in series until all product back log items are completed anda fully functional software release is available for the customer.

Boards Menu

The boards menu is where you can manage work items, list themin backlogs as details, show them as cards on boards,and plan your weekly work in sprints. Of course, any majorsoftware release will have multiple sprints and finding a product backlog item mightbe challenging. Therefore, the queries menu allows you tosearch all the meta data about your project.

The image below shows you the five menu items that you will be working with ifyou are the project manager or scrum master. Azure DevOps supports both theScrum and Kanban agile methods. I will be only covering Scrum in the talk.Please see Microsoft's onlinedocumentation for details.

From the boards screen (blade), we can add a new user story. Userstories are a way to group multiple related work items into one unit. I amnaming this story "Modernize Geography Table". The storyhas been assigned to Dilbert as the project lead. We can see this story ispart of sprint "Iteration 1" for the "advwrks4tips19" project.I added a description describing the two tasks associated with this story.

After saving our information about the story, we can return to the boards screen.The new story shows up as a card on the board under the new status.Right clicking the card gives us several options. We can add a task, a bug,or a test to this story. Also, we can move the story to another iteration(sprint) or create a new branch in our code repository.

Right now, we want to create two tasks associated with story. The imagebelow shows the right click menu option for cards.

Each object defined in the agile project is given a unique number. We cansee that the story is number 2. The image below shows the two named tasks(items) associates with the story. I moved to story from new to active status.The next step is to enter details about each task as well as a time estimate forcompletion.

The first step in adding GPS information to the Geography dimension table isto create two new fields. I am over estimating that the actual change willtake a day or eight hours. Two hours have already been spent on the task andsix hours are remaining. See the image below showing the details behind changingthe table.

The second step in adding GPS information to the Geography dimension table iscreate UPDATE statements that can be executed against an existing table. Iam going to write a PowerShell program to lookup the GPS coordinates using GoogleMaps API and create a T-SQL file with the requiredUPDATE statements.

The following five fields from the DimGeography table are requiredto get a GPS value for each record. The primary key to each record and thetwo new GPS values are required to create the final update script. Since theaddresses are not exact locations, we will be using the center most location ofa given postal code area.

If you are interested in how the update statements were created, please downloadthe zip file from here and read the code. This script can be added as a postdeployment task in our database project. This tip covers the design patternused in previousarticle that I wrote. Now that we have our tasks defined, it is time toplan a sprint and figure out the work load for each team member.

Sprints Menu

The sprints screen has three sub menus: the task board, the backlog and thecapacity. We can see that all work is currently being done by Dilbert.Let's add "craftydba" to the team and shift the work assignments around.

The capacity screen is where we can add users and dictate how much time theyhave each day to devote to a given project. Since the "craftydba" is a busy person, (s)he can only spent 25 percent of the weekon this project. That equates to 2 hours per day. The image below showsthis resource addition to the team.

To recap the results of our work, the image below shows work item number 3,which is the addition of two fields to the table, has been assigned to "craftydba". The remaining work is assigned to Dilbert.Both tasks assigned to the team should be completed this week given the availablecapacity.

Now that we know how to create back log items and plan sprints, how do we linkthese tasks to code branches in our Git repository?

Linking Code Branches to Work Items

The Azure DevOps service allows you to create a branch from either theBoards or Repos menus. I like creating thebranch for the Repos menus since you are allowed to attach as many work items asyou like. I am creating a new branch called geo-project usingthe appropriate dialog box.

If we open the Visual Studio project that is linked to source control, we cansee that the new branch shows up under remotes. We need to use the branchesmenu in team explorer to checkout a copy of the branch for local use.

If the action completed successfully, the local and remote branches should mirroreach other. The image below is the state in which you want Visual Studio tobe in.

The next step is to open the file named "DimGeography.sql"and add the two new fields to the table. Upon saving the file, we see thata check mark appears since the code has changed.

I am assuming that you deployed and tested the changes to a local developmentserver. Now that we have good code, we need to check the changes in.Use the Changes menu under team explorer to complete this action.I added an appropriate description to track the change. Choose the commitall to push changes to both the local and remote repositories.

The History menu under the team explore brings up a menu that shows all the changesin the local repository. We can see that a new branch has been created andchecked in.

It is always good to double check your work. If we look at the code explorerin Azure DevOps, we can see the same change being checked into the geo-projectbranch.

In a nutshell, linking a code branch to a series of work items is quite easyto do with Azure DevOps.

Merging Code Branches

An agile software development team might have several branches of code beingworked on at the same time. After successfully unit testing the code changes,the project manager will request an integration test to be executed. Thatmeans all the separate branches need to merged into one branch.

The Pull Requests menu can be used to initiate the merge action.There are two gateways in which users are asked to fill in information. First,the pull request has to be approved with a comment. Second, the pull requesthas to be marked as complete.

The complete action requires additional check boxes to be marked.

The above image shows the dialog box when that pulls the geo-projectbranch into the master branch. I am showing the extreme exampleof a merge in which the branch is deleted and changes are squashed. All commithistory for the branch is lost. See diagram below for process flow.

A typical merge adds the file changes to the final branch. In our case,we are using master as the final branch. The files and the commit historyare retained in the feature branch. Please compare diagrams to see difference.

The merge action of the remote code repository will be reflected in Visual Studioright away. However, we have a local copy of the geo-project repository.To remove this branch from Visual Studio, we need to use the Syncmenu in Team explorer.

The above image shows the local copy of the geo-project branch. The imagebelow shows how to synchronize the local and remote branches. We can see thatthe comment from the pull action in Azure DevOps made its way down to the team explorer.

Last but not least, taking a look at the branches menu in team explorer willreflect the state of both the local and remote branches. Be careful when usingthe squash commit action since any history of the feature branch is destroyed.

Organizing Back Log Items

There are five different statuses that can be associated with a backlog item.I have already talked about the new and activestatuses. The resolved status can be used when a bug itemhas been added and the closed status reflects a closed item.Sometimes, a request is added as a backlog item but has been decided to not implementthe task. This item can be set to a removed status.The diagram below shows a state diagram for item statuses.

So far, we have talked about how stories can be used to groupitems. However, some project managementtools implementthemes, initiatives, epics, user stories and items for grouping of tasks.One way to think of this hierarchy is to look at a Russiandoll in which a smaller dolls fit into a larger doll.

A work item is a task that can be completed in hours.A story is a group of tasks that can be completed in days.A feature is a group of stories that can be completed in weeks.An epic is a group of features that can be completed in months.Azure DevOps allows the project manager to use these four concepts.

If we go back to the boards menu, we can use the right most drop down box tolook at features. The image below shows the "Modernize AdvWrksProgram" feature that I created. Changing the geography tableis just one story under this feature.

If this was a real-life example, I would rename the title of the feature tobe "AdvWrks - DB Changes" to reflect any back-end changes that are required tothe system. The "Adv Wrks - GUI Changes" wouldreflect any front-end changes required by the system. Of course, we wouldhave to add a Visual Studio project to the code repository that contains our webapplication.

Last but not least, I would create an epic named "Modernize AdvWrksProgram" to group both the front and back end features. Bydefault, epics are not enabled in Azure DevOps. Use the settings icon or thegear to bring up the settings dialog box. Make sure the epics option underbacklog navigation levels is checked to enable.

Summary

Today, companies are creating agile teams in which members collaborate with eachother, teams self-organize the work load, and cross functional skills sets of themembers allow for rapid delivery of work items. It is not surprising thatMicrosoftAzure DevOps combines scrum project management tools and software version controlinto one service.

The first step in leveraging this Scrum tool is to add team members to the DevOpsaccount. We want to figure out the capacity of each team member for resourceplanning.

The second step is the addition of product backlog items to the backlog.Every software project has a dependency graph on how the components will be createdor modified. The project manager can use epics, features and stories to groupthe product back log items into a logical hierarchy.

The third step is to plan a sprint. This is choosing all the items thatcan be accomplished within the two-week period and assigning the items to team members.The self-organizing developers can weigh in at this time about which tasks willbe checked out as a feature branch. One or more branches may be checked outat this time.

The fourth step is to have each developer pull down a feature branch. Designing,deploying and testing the new or modified code can call be done with Visual Studio.I did not go over creating automatic test cases for database projects. I leavethis open as a topic to cover in the future. After completion of the assignedtasks, the code changes are checked into the repository.

The fifth step is to create a pull request so that all changes get merged intothe final release branch. Some organizations use the masterbranch for this purpose. A final unit test of all the feature branches thatwere created during a sprint is required to test the completeness of the system.

The great thing about using this tool is the ability to back out a feature branchif bugs were introduced. The commit history captures the incremental detailsabout the changes and the links to the work items shows the reasoning behind thechange. In summary, Azure DevOps allows both agile project planning and softwareversion control to co-exist.

Next Steps

• Leveraging pre-deployment and post deployment scripts
• Using Azure Test Plans for Quality Assurance
• Continuous Database Deployment with Azure DevOps

About the author