What is Azure DevOps? Learn how to start using Azure DevOps

tudip-logo

Tudip

15 May 2020

Introduction

Azure DevOps is a Project management tool to manage the development of a project. It is used for the following purpose for the development of software:

  • Project Management tool:
    • Azure DevOps is used as a project management tool to keep track of the progress of  development of a software
    • Built-in wiki to store and share the details of the project with the team
  • Source Control tool:
    • Azure DevOps is used as collaborative software development
    • Git repositories for source control of the development code
  • Build and Deployment:
    • Azure DevOps is used for managing multiple releases cycle of a project

Registration and creating teams

  • Creation of a Project in Azure DevOps

    • We can have multiple projects and handle them with a single login
    • Set the value of version control as Git (This is for the purpose of developers)
    • Set the value of version control as Scrum (This is for the purpose of the analysts and for managing multiple releases)
  • Add members to the projects

    • Add a particular person’s email address or a group while creating a project
    • The mentioned people would be notified on their emails
    • We can review the team members and we can add more team members in the settings
    • We can manage the access and the roles, like project administrators, build admins, contributors, stakeholders
    • We can create multiple teams and assign other members to it with their respective roles
    • We can manage permission and accessibilities for each role
  • Project configuration

    • Here we manage multiple releases of a project
    • One must be a member of the Project Administration group to access project configuration
    • Steps to be followed for project configuration:
      • Step 1: Click on the “Project configuration”
      • Step 2: Click on “Sprint”
      • Step 3: Create your own iteration (Example: TV2Consulting project)
      • Step 4: Set the start date and End date
        • We can create multiple sprints for one project
      • Step 5: Click on “New child”
      • Step 6: Assign a name to it (Sprint 2)
      • We can create a number of iterations
  • Area

    • When we gather some requirements and put it in one folder, we follow the same understanding for Areas in VSTS
    • Steps to be followed to create “Area”:
      • Step 1: Click on “Team Configurations”
      • Step 2: Click on “Create Area” for each team
      • Step 3: Click on “Iterations” and make it available them for the teams
    • Conditions to make an iteration available:
      • Go to settings
      • Assign respective names to each iteration
      • Select all iterations that the team needs
    • Understanding the relations between each element and their validations:
      • Epic:
        • Valid for multiple releases
      • Feature:
        • Valid for multiple sprints
      • User story
        • One sprint
      • Tasks:
        • Valid for one member

Epic

  • It is always a good habit to add acronyms for good and easy search result
  • Use the same acronym for all the features, Product backlogs, and tasks for good business handle
  • The senior BA or the team members assigned with Project administrator have access to create Epics

How to create an Epic of a project:

  • Step 1: Click on “Work Items”
  • Step 2: Click on “New Work Item”
  • Step 3: Select “Epic” from the drop-down
  • Step 4: Click on “Title”
    • It is a good habit to mention an abbreviation while creating a task.
    • Example: TALA: Elastic search
  • Step 5: Click on “Assigned to”
    • Select the team member from the drop-down menu and the Epic would be assigned to that team member
  • Step 6: Click on “Tags”
    • Tags are used for easier search using one keyword
    • We can create tags while creating an Epic
  • Step 7: Click on “Area”
    • We can assign a project name under “Area”
  • Step 8: Click on “Iteration path”:
    • We can assign the sprint to an Epic
  • Step 9: Click on “Description”:
    • We can write details of the Epic
    • This would be an optional field, so if not necessary we can leave it as it is
  • Step 10: Click on “Acceptance Criteria”
    • We can mention a necessary condition of the Epic that need to acknowledge other team members
    • Example: “Make sure all requirements are completed”.
  • Step 11: Click on “Discussion”
    • We can tag members under the tags and the team members would be notified using (@), they will receive an email.
    • Example: @patrick, please check this out.
  • Step 12: Fill all necessary fields under “Details”:
    • Priority: Priority of the Epic
    • Efforts: Efforts need to complete the architecture under the Epic
    • Business values: mention the value area for that Epic
    • Time Criticality: Deadline of the Epic to complete
  • Step 13: After filling all the fields we can click on the “Save” button

Features

Path to move to an Epic:

Board -> Backlogs -> Drop-down -> Backlog item -> Select one Epic

To split an Epic into features:

  • Step 1: Click on plus (+) icon beside Epic on the board
    • Only Project Admins and Collaborators  can split an Epic into features, no other role has the access to split an Epic
    • Projects created with the Team Configuration as “Scrum” can only view the Epics and create features for the Epics

How to create a Feature:

  • Step 1: Click on ‘Boards’
  • Step 2: Click on the drop-down “Epic”
  • Step 3: Select the item “Feature”
  • Step 4: Fill all fields with valid information
    • Title:
      • Provide the title of the feature, recommended to write the abbreviation in the beginning
    • Area path and Iteration path:
      • The Area Path and Iteration path would be the same as the Epic, we can change it accordingly
    • Description:
      • Mention all associated details of the feature
    • Acceptance Criteria:
      • Mention the condition, if any, under this field
      • Example: Tag one member, we can mention the details of the Epic it is related to
    • Details:
      • The field is not mandatory for creating a feature, depending on the organization
    • Effort:
      • Total time of the user stories, under the feature would be the effort of the feature
    • Time Criticality:
      • The defined duration required to complete the work
    • Business Values:
      • The business values can differ depending on the organizations
      • It can be “Business”, “Architecture”.
    • Note: 
      • We can create multiple features for each Epic
      • Requirements that we can complete in one sprint should be created as features
      • Click on the plus icon beside each feature from the board
      • We can create a PBI or a Bug for a feature

Product Backlog

  • Product backlogs are the user stories of a project
  • Product backlogs would be the requirements that we can complete in one sprint
  • We can create multiple tasks for one Product Backlog
  • We can use the same acronym used in the Epic, to the title of the product backlog (Recommended to use a common acronym throughout the flow for easy search)
  • We can provide a description and other details depending on the organization

How to create a Product Backlog:

  • Step 1: Click on “+” sign beside the features on the board
  • Step 2: Tags:
    • Add  tags to the product backlogs
  • Step 3: Follow:
    • Team members can click on “Follow” so that they will receive all updates for all changes occur in the product backlogs
  • Step 4: Attachments:
    • We can attach any document associated with the product backlog
  • Step 5: History:
    • We can view the History of the actions performed on the Product Backlog from the creation of the product backlog
  • Step 6: Title:
    • Provide the title of the product backlog, recommended to write the abbreviation in the beginning
  • Step 7: Area path and Iteration path:
    • The Area Path and Iteration path would be the same as the Feature, we can change it accordingly
  • Step 8: Description:
    • Mention all associated details of the product backlogs
  • Step 9: Acceptance Criteria:
    • Mention the condition, if any, under this field
    • Example: Tag one member, we can mention the details of the Epic it is related to
  • Step 10: Details:
    • The field is not mandatory for creating a product backlog, depending on the organization
  • Step 11: Effort:
    • Total time of the user stories, under the product backlog would be the effort of the feature
  • Step 12: Time Criticality:
    • The defined duration required to complete the work
  • Step 13: Business Values:
    • The business values can differ depending on the organizations
    • It can be “Business”, “Architecture”.

Tasks 

How to create a Task:

  • Title:
    • The title of the task should contain a brief understanding of the task
  • Assigned To:
    • Here we need to assign the developer’s name
  • State:
    • When a task has created the state of the task will be “New”
    • When a developer picks a task, the state will be “In Progress”
    • When a developer completes the task, the state needs to be updated to “Resolved”
    • The developer needs to assign the task to QA to testing and then the QA will update the task to “Done”
  • Area:
    • Project name on which the developers are working (for eg. Main\OTT, Main\OTT Monitoring, and Diagnostics)
  • Iteration path:
    • In this field, we can mention the sprint name.
  • Description:
    • The detailed information of the task needs to be provided in this section
  • Remaining work:
    • The remaining work hour should be the same as the original estimate hours while the task is created
    • When the developer completes the task, the remaining work hour should be 0
  • Original Estimate:
    • The estimated duration of the task needs be mentioned here, the minimum duration can be 1 hour and the maximum duration can be provided as 18 hours
  • Efforts:
    • When a developer starts working on a task, the developer needs to update the efforts
  • Dev Testing:
    • The developer needs to mention the hours spent in dev testing of the task
  • Platform:
    • While the task is created, the platform to which the task belongs to needs to be mentioned
  • Dev Testing Steps:
    • When the developer updates the task to the “Resolved” state, the developer needs to explain the Dev Testing steps.

Miscellaneous features of the User stories

Follow a User Story

  • We can tag team members of the project to notify them and keep them updated with the actions performed on the task.
  • The tagged team members would be notified via emails

Attachments/ Documents

  • We can attach the associated documents to the tasks
  • We can attach files to the tasks

History

  • We can track the activities performed on each task
  • We can know the changes performed on each field along the details of the responsible team member

Request a quote