Hands-on Azure Boards PDF

Chaminda Chandrasekara and Pushpa Herath Hands-on Azure Boards Configuring and Customizing Process Workflows in Azure DevOps Services Chaminda Chandrasekara Dedigamuwa, Sri Lanka Pushpa Herath Hanguranketha, Sri Lanka Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the book’s product page, located at www.apress.com/978-1-4842-5045-7. For more detailed information, please visit www.apress.com/source-code. ISBN 978-1-4842-5045-7 e-ISBN 978-1-4842-5046-4 https://doi.org/10.1007/978-1-4842-5046-4 © Chaminda Chandrasekara and Pushpa Herath 2019 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Distributed to the book trade worldwide by Springer Science+Business Media New York, 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders- [email protected], or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. Let this book be a beginning point of thousands of future Azure Boards teams to run their software projects effectively and efficiently. Introduction Technology is evolving faster than ever before, and modern software is expanding into each and every industry and sector in society. Most businesses and people’s day-to-day lives are closely intertwined with technology and software. To come up with innovative solutions for the software needs of modern industry, it is vital for software firms to continuously improve their software delivery processes. The continuous improvement of software delivery processes requires the work being carried out to be tracked, effectively providing traceability and visibility. Predictability plays a key role in the success of this work and is essential for identifying trends or work patterns in teams, risks, and bottlenecks, and for addressing them in a timely manner with proper capacity, risk management, and skill planning. Azure Boards comes with Kanban boards, backlogs, team dashboards, and custom reporting to help you turn an idea into a working piece of software. Comprehensive traceability is available with flexible work item tracking, allowing you to plan your work in iterations/sprints, and Azure Boards allows you to track your work from idea to the completion of implmenting the idea. Azure Boards—in combination with Azure repos, pipelines, artifacts, and tests—offers visibility and traceability in every step of the software delivery process. As the first book in the Hands-on Azure DevOps series, Hands-on Azure Boards covers the capabilities of Azure Boards comprehensively. We describe the features of the built-in templates that you can use to run your software delivery teams with Agile, Scrum, or CMMI processes. We give hands-on lessons for configuring Azure Boards to behave in the way you want and to emit the information you need, including when customizing and building your own process workflows. These lessons will give you a broader and in-depth understanding of the tool. Advanced topics include administering and setting up a command-line interface, using a REST API for custom reporting or any other needs, setting up security and permissions, and setting up and managing small to large teams. Hands-on Azure Boards is the book that project managers/Scrum masters, team members, and anyone involved in the software delivery process can use as a day-to-day reference manual to improve the way they work. You can use it to convert your software delivery process to a real implementation using the Azure Boards capabilities that are available in the Azure DevOps on-premises servers and services. Acknowledgments We are thankful for all the mentors who have encouraged and helped us during our careers and who have provided us with so many opportunities to gain the maturity and the courage we needed to write this book. We would also like to thank our friends and colleagues who have helped and encouraged us in so many ways. Last, but in no way least, we owe a huge debt to our families, not only because they have put up with late-night typing, research, and our permanent air of distraction, but also because they have had the grace to read what we have written. Our heartfelt gratitude is offered to them for helping us make this dream come true. Table of Contents Chapter 1:Getting Started with Azure Boards Lesson 1-1.Creating an Azure DevOps Organization Lesson 1-2.Creating a Public/Private Agile Project Lesson 1-3.Comparing Project Templates Work Item Types Process Templates Work Item State Flows Lesson 1-4.Navigating Azure Boards Summary Page Dashboards Wiki Work Items Boards Backlogs Sprints Queries Lesson 1-5.Customizing Organization Settings Lesson 1-6.Previewing Features and Themes Summary Chapter 2:Setting Up a Team Project Lesson 2-1.Creating a Team Lesson 2-2.Defining Common Project Settings Project Settings Lesson 2-3.Setting Up Areas Project Areas Team Areas Lesson 2-4.Setting Up Releases and Iterations Team Project Iterations Team Iterations Lesson 2-5.Setting Up Team Members and Permissions Lesson 2-6.Defining Team Capacity and Days Off Summary Chapter 3:Working with Backlogs and Boards Lesson 3-1.Understanding the Backlog Hierarchy Lesson 3-2.Defining a Backlog Organizing Epics in a Hierarchy Adding Features to Epics Adding Stories to Features Adding Tasks to User Stories Changing the Parent Using the Work Item Context Menu in the Backlog View Lesson 3-3.Exploring Important Work Item Fields Common Important Work Item Fields Lesson 3-4.Selecting Work to Move to an Iteration Lesson 3-5.Using Kanban Boards and Task Boards Kanban Boards Task Boards Lesson 3-6.Working with a Bug Work Item Managing Bugs with Tasks Managing Bugs with Requirements Bugs Not Managed with Requirements or Tasks Summary Chapter 4:Work Item Notifications, Tags, and Customization Lesson 4-1.Setting Up Work Item Tags Lesson 4-2.Setting Up Work Item Notifications Lesson 4-3.Customizing a Kanban Board’s Card Customizing Fields Adding Card-Style Rules Setting the Tag Color Customizing Tests Lesson 4-4.Customizing a Kanban Board’s Settings Customizing Columns Using Swimlanes Reordering Cards Setting Up a Status Badge Summary Chapter 5:Customizing the Process Lesson 5-1.Creating an Inherited Process Lesson 5-2.Editing Work Item Types Editing the Work Item Color and Icon Modifying the Layout of the Work Item Form Editing an Inherited Field Editing an Inherited Group Adding a New Page to the Layout Adding a New Group to the Layout Adding a Custom Field Lesson 5-3.Changing the State Workflow of a Work Item Lesson 5-4.Adding New Work Item Types Lesson 5-5.Adding a Top-Level Backlog Lesson 5-6.Defining Custom Work Item Rules Summary Chapter 6:Visualizing and Reporting in Azure Boards Lesson 6-1.Exploring the Out-of-the-Box Reporting of Azure Boards How the Work Is Progressing? Bulges in Cumulative Flow Flat Lines and Scope Changes Lesson 6-2.Creating Personal Queries Lesson 6-3.Sharing Queries with the Team Favorite Queries Lesson 6-4.Writing Complex Queries Lesson 6-5.Creating Charts with Queries Lesson 6-6.Adding Charts to the Dashboard Lesson 6-7.Creating Dashboards Lesson 6-8.Adding Widgets to a Dashboard Lesson 6-9.Using Widgets to Visualize Work Items Summary Chapter 7:Handling a Large Team in a Team Project Lesson 7-1.Understanding the Requirements of Multiple Teams Lesson 7-2.Configuring Areas and Teams to Isolate Backlogs Isolating the Backlogs Achieving a Hierarchical Team Structure Sharing the Same Backlog with Multiple Teams Lesson 7-3.Sharing the Same Iteration with Multiple Teams Lesson 7-4.Working with Different Release Cadences for Teams Lesson 7-5.Sharing a Team Member Across Multiple Teams Summary Chapter 8:Azure DevOps Security Options Lesson 8-1.Adding Users to Azure DevOps Lesson 8-2.Setting Up Azure DevOps Organization-Level Security Policies and Permissions Lesson 8-3.Enabling Access to External Users in Organization- Backed Azure DevOps Accounts Lesson 8-4.Granting a License for Extended Paid Features Lesson 8-5.Setting Up Organization-Level Security Options for a Process Template Lesson 8-6.Setting Up Project-Level Security Options Iteration Permissions Area Permissions Shared Queries Permissions Lesson 8-7.Setting Up Team-Level Security Lesson 8-8.Setting Up User-Level Security Options Personal Access Token Alternate Credentials SSH Public Keys Summary Chapter 9:Working with REST APIs and the CLI Lesson 9-1.Understanding the REST API Components The Request URI HTTP Request Message Header Fields HTTP Request Message Body HTTP Response Message Header Fields HTTP Reponses Message Body Fields Lesson 9-2.Using a REST API from a Browser Lesson 9-3.Using a REST API with PowerShell Authorization Calling the REST API WIQL Lesson 9-4.Creating a Work Item with a REST API Lesson 9-5.Getting Started with the Azure DevOps CLI Showing a Work Item Updating a Work item Summary Chapter 10:Using Extensions with Azure Boards and Linking with GitHub Lesson 10-1.Using Extensions in Azure DevOps Lesson 10-2.Using Work Item Layout Extensions Lesson 10-3.Using a Few Other Useful Extensions Delivery Plans Estimate Feature Timeline and Epic Road Map Lesson 10-4.Linking GitHub to Azure Boards Summary Index About the Authors and About the Technical Reviewer About the Authors Chaminda Chandrasekara is a Microsoft Most Valuable Professional (MVP) for Visual Studio ALM and Scrum Alliance Certified ScrumMaster. He focuses on the continuous improvement of the software development lifecycle. He works as the Lead DevOps Engineer at Xameriners, Singapore. Chaminda is an active Microsoft Community Contributor (MCC) who has been recognized for his contributions in Microsoft forums, TechNet galleries, wikis, and Stack Overflow, and he contributes extensions to Azure DevOps Server and Services (formerly VSTS/TFS) in the Microsoft Visual Studio Marketplace. He also contributes to other open source projects on GitHub. Chaminda has published three books with Apress, and he blogs at https://chamindac.blogspot.com/. Pushpa Herath is a DevOps engineer at Datavail Lanka (Pvt) Ltd. She is an author, blogger, and speaker at public technical events and has many years of experience administering, configuring, and coaching Azure DevOps and test automation engineering. Pushpa blogs about technology at https://devopsadventure.blogspot.com/. Pushpa has experience with Microsoft tools (C#, Azure DevOps, SQL Server, Azure Platform Services) and other DevOps tools (Octopus, Jira, Jenkins). She is also the coauthor of Hands-On Functional Test Automation , published by Apress. About the Technical Reviewer Mittal Mehta has 15 years of IT experience and currently works as a configuration manager. He has worked in the TFS, C#, Navision, build-release, Azure DevOps, automation, and configuration areas for the past eight years using Microsoft technologies. © Chaminda Chandrasekara and Pushpa Herath 2019 C. Chandrasekara, P. Herath, Hands-on Azure Boards https://doi.org/10.1007/978-1-4842-5046-4_1 1. Getting Started with Azure Boards Chaminda Chandrasekara1 and Pushpa Herath2 (1) Dedigamuwa, Sri Lanka (2) Hanguranketha, Sri Lanka Lesson 1-1. Creating an Azure DevOps Organization Lesson 1-2. Creating a Public/Private Agile Project Lesson 1-3. Comparing Project Templates Work Item Types Process Templates Work Item State Flows Lesson 1-4. Navigating Azure Boards Summary Page Dashboards Wiki Work Items Boards Backlogs Sprints Queries Lesson 1-5. Customizing Organization Settings Lesson 1-6. Previewing Features and Themes Summary The objective of this chapter is to get you started with Azure Boards in Azure DevOps. You’ll start by creating a new Azure DevOps organization. You’ll learn about different process templates and get a good overall understanding of Azure Boards in this chapter before diving into more details in the coming chapters. Lesson 1-1. Creating an Azure DevOps Organization This lesson explains how to create a new Azure DevOps organization. Prerequisites: You need to have a Microsoft account ( https://account.microsoft.com/account ). Go ahead and create a new Azure DevOps project by following these steps: 1. Go to dev.azure.com. If you have a Microsoft account, you can log in by clicking “Sign in to Azure DevOps.” Otherwise, you can use the “Start free” option. See Figure 1-1. Figure 1-1 Azure DevOps login page 2. After logging in to Azure DevOps or going through start free process, you can create a new DevOps organization. Click new organization after logging in. 3. Give the new organization a name and select the organization region from the drop-down. The region defines the primary Azure region for the Azure DevOps organization being created. However, your data is replicated to other Azure data centers to assure high availability. You can see that the organization name is sldevop in this example. After entering the relevant details, click the Continue button to create an organization. See Figure 1-2. Figure 1-2 Naming the organization This will take about a minute, and then you will be redirected to the start page of the new Azure DevOps organization. In this lesson, you created a new Azure DevOps organization to be used in the rest of the lessons in the book. Lesson 1-2. Creating a Public/Private Agile Project In this lesson, we will discuss how to create private and public projects with Agile process templates. When you create a new DevOps project, you can create the project as a public project or a private project. If the project is private, only authorized people can access the project. If you create a public project, anyone with a Microsoft account can access the project, which is really useful when you are working on open source projects. Prerequisites: You need to have an Azure DevOps organization. Let’s create a private project with Agile as the process template and Git as the version control system. 1. Go to dev.azure.com and log in with your Microsoft account credentials. 2. In the Organizations section, select the organization you created in the previous lesson. 3. When you access a newly created organization, you will get the project creation page as the start page by default. If there are projects available in an organization, you will see the Create Project button in the top-right corner of the Azure DevOps start page. 4. Enter the project name, select Private, set Git as the version control system, and set Agile as the work item process. Then click “Create project” to create the project. See Figure 1-3. Figure 1-3 Creating a new DevOps project Now you have created a new DevOps project with the Agile process template. Azure DevOps provide four process templates. Those are Basic, Agile, CMMI, and Scrum. You can select the preferred process template from the “Work item process” drop-down list when creating a new project. This lesson explained how to create a new Azure DevOps project with Git as the version control system and Agile as the process template. Furthermore, you learned it is possible to create projects with Basic, CMMI, and Scrum process models. Let’s learn more about these project templates in the next lesson. Lesson 1-3. Comparing Project Templates Azure DevOps facilitates four main process models: Basic, Scrum, Agile, and CMMI. You can discover the differences between these process models by referring to the comparative explanation in this lesson. Work Item Types Before understanding what a process model is, we have to define work items in Azure DevOps. A work item is any type of work you do as a team member or as a team. A work item type (WIT) in Azure DevOps comes with fields and a specific workflow to enable you to track the work being carried out by the team. Feature, User Story/Requirement/Product Backlog Item, Bug, Task, Test Case, and so on, are some of the default available work item types. You can even introduce your own work item types and alter the behavior of the existing default work item types. Process Templates With this understanding, let’s look at the available process templates in Azure DevOps. 1. Basic: Most light-weight process models provide three work item types as default work items: Epic, Issue, and Task. A team that wants to get started simply and model the process as they continue to work with Azure DevOps can choose this template. 2. Scrum: This template is best suited for the teams that follow Scrum as their process model. Bugs are tracked along with product backlog items by default in the Scrum template, and you can configure Boards to track bugs in the same level as task work item level. Tasks in this process template track only the remaining work. 3. Agile: Teams that are using Agile methodologies including Scrum can use this process model. By default, bugs are tracked with the task level in the Agile template, but you can configure them to be tracked with the user stories level. 4. CMMI: Teams following the capability maturity model and using a more formal process to track change requirements can use this template to track their work. Requirements, change requests, reviews, and risks can be tracked, enabling the teams to follow and adhere to the CMMI process standards. Figure 1-4 shows a process template overview comparing each process model. Figure 1-4 Process model overview In the Agile and CMMI process models, you can configure the Bug work item to be tracked along with the user story/requirement level, similar to the Scrum template’s default Bug work item’s tracking behavior. In the Scrum process, you can set bugs to be on the same level as tasks. These configurations will be discussed in later chapters when you learn how to configure Azure Boards in hands-on lessons. There are a common set of work item types shared in all process templates. For managing tests, there are the following work item types: Test Plan, Test Suite, Test Case Shared Steps and Shared Parameters. Feedback Request and Feedback Review are used to manage feedback on the project. Code Review Request and Code Review Response are two work item types that support managing code reviews. All these different types of work items will be discussed in relevant areas of this book. Work Item State Flows Work items in each process model contain a state field representing the current state of the work item. The Basic template contains the simplest state workflow out of the four process templates available. Figure 1-5 shows the states in each template by default. You can introduce your own states and modify templates with inherited templates; this will be discussed in Chapter 5 of this book. Figure 1-5 Work item states The work item states are categorized into state categories in Azure DevOps. Each process template contains the Proposed, In Progress, and Completed state categories. The Removed state category is used in the Scrum and Agile templates. The Resolved state category is used in the Agile and CMMI templates. Figure 1-6 shows state categories used in each template and the states assigned to them by default. You can see the Resolved state used in both the Resolved category and the In Progress category in Agile and CMMI. This is because in the context of a bug, the Resolved state is used in the Resolved state category in both templates. However, User Story/Requirement in both templates has the Resolved state under the In Progress category. Figure 1-6 State categories In addition to the workflow states when transitioning between the work item states, you can select a reason for state transition. Implementation Started is one such reason when you move a work item from the New to Active state. These reasons are further explaining the state transition. You’ll learn more about the state transitions in each work item type in later chapters of this book. Figure 1-7 shows default transitions of the User Story work item in the Agile template. Figure 1-7 User Story default transitions In this lesson, we identified the key differences between the process templates in Azure DevOps. This information will be useful when you are choosing the right template for your team. Lesson 1-4. Navigating Azure Boards You can navigate through almost all the main pages in Azure DevOps with the left-side menu. This lesson will give you a brief understanding of the available features in the Overview and Boards sections. Hover your mouse over the Overview menu item in the left-side menu. Then you will see Summary, Dashboard, and Wiki in the model pane. We’ll now identify the features in each area. Summary Page You can get to the Azure DevOps Summary page by going to the left menu of an Azure DevOps project, selecting the Overview menu, and selecting the Summary submenu item. See Figure 1-8. Figure 1-8 Summary submenu item On the Summary page, you will find five sections. See Figure 1-9. Figure 1-9 Summary page 1. Edit project name: Click the pencil icon next to the project name. See Figure 1-10. After clicking the pencil icon, you will navigate to the project’s edit page. Figure 1-10 Project’s edit pencil icon On the project’s edit page, you will find the sections shown in Figure 1-11. Figure 1-11 Project properties edit page A. Edit the project name. B. Add or edit the project description. C. View the process template. D. Change the project visibility options to private or public. E. Save the changes. F. Add project administrators. G. Remove services from the project by clicking the button in front of each service. After clicking the button, the Remove Service pop-up will appear. As an example, if you click the On button in front of Boards, a pop-up will open that has a Remove Boards button on it. See Figure 1-12. After clicking the Remove Boards button, the Boards service will be removed from the project. Figure 1-12 Remove service pop-up for Boards service H. Delete the project by clicking the Delete button. 2. Project welcome message section: You can see a welcome message and buttons to navigate through the project. This area has buttons to navigate to boards, repos, pipelines, test plans, and artifacts. Also, there is a link to navigate to the service management area of a project’s edit page. See Figure 1-13. Figure 1-13 Project welcome message section 3. Project Status section: This area displays project progress charts. You will explore this in later chapters and in the other books in the series. 4. Members: The names of all the project members are displayed here. See Figure 1-14. It is possible to view more information about each member by clicking the name of the member. Figure 1-14 Names of project members 5. Add new members: This section has two buttons. The gray button indicates the current project type. This can be either private or public. The second button is the Invite button. See Figure 1-15. Figure 1-15 Current project type and Invite button After clicking the Invite button, the left model pane will open. You can add and search for names of team members. Then click the Add button to add members to the dashboard. See Figure 1-16. Figure 1-16 Inviting members to the project Dashboards Dashboards help you visualize the progress of the project. Azure DevOps provides a facility to create multiple dashboards. You can add default widgets and additional widgets from the marketplace to visualize the project progress in these dashboards. Let’s look at Figure 1-17 to understand the options in the dashboards. Figure 1-17 Azure DevOps dashboard 1. Add new dashboards, navigate between dashboards, search dashboards, and browse all dashboards options that are available. 2. The team profile settings in the right-side model pane will open when you click this icon. In the team settings section, you can see the names of the project members and navigate through the project. There is a capability to navigate to boards, backlogs, sprints, and dashboards. See Figure 1-18. Figure 1-18 Team settings 3. By clicking the edit button, it is possible to add, edit, move, or resize the dashboard widgets. Azure DevOps provides a facility to add marketplace widgets, as well as charts generated using the project queries, to the team dashboard. See Figure 1-19. Figure 1-19 Adding widgets 4. You can refresh the dashboard by clicking this refresh icon. 5. After click this cogwheel icon dashboard setting, the window opens. You can change dashboard settings through the pop-up. 6. Change the page view to full-screen mode. 7. In fresh projects, you will find this button. This will help you to navigate to the widget management area mentioned in Figure 1-19. Wiki Azure DevOps has a wiki section that provides a facility to create your own documentation. There are two options for creating a wiki. See Figure 1-20. This lesson explains how to create your own wiki. We’ll discuss how to publish code as a wiki option in a future book (Azure Repos) of this book series. Publishing code as a wiki is a mechanism that allows you to create a wiki by referring to.md files in the repository folder. Figure 1-20 Adding a wiki page After clicking the Create Wiki button, you will be navigated to the wiki’s edit page. See Figure 1-21. Figure 1-21 Wiki’s edit page 1. The wiki has three header options. You can click the down arrow and then select the headers. 2. Add bold text to the wiki. 3. Add italic text to the wiki. 4. Add a link to the wiki. 5. Add code to the wiki. 6. Add a bulleted list to the wiki. 7. Add a numbered list to the wiki. 8. Add a task list to the wiki. 9. Add a table to the wiki. 10. Mention work items in the wiki. 11. Insert files to the wiki. 12. Add HTML to the wiki. 13. After clicking more options, you will be able to see other available features of the wiki. The options are as follows: Insert table of contents Insert videos Insert Yaml tags Insert formulas Insert team members Insert query results 14. You can select “Edit only view,” “Preview only view,” or “Edit and preview view.” 15 S th iki 15. Save the wiki. 16. You can add a new page from the section display after clicking the side pane named Pages. So far, you have navigated through the submenu items under Overview. The next section will navigate you through the Boards menu. You can find work items, boards, backlogs, sprints, and queries as submenu items of Boards. Work Items You can find the Work Items submenu item under Boards of the Azure DevOps project. See Figure 1-22. Figure 1-22 Work Items submenu item in the side menu Let’s identify the features available under Work Items. See Figure 1- 23. Figure 1-23 Work Items page 1. You can filter work items using the filters available in this drop- down. The following are the filtering options: Recently updated: Displays recently updated work items Assigned to me: Displays work items assigned to the specified team member who is logged in Following: Displays work items that are marked as Following Mentioned: Displays work items that have discussions with the mentioned tag My activity: Displays work items with details of activities the member performs on each work item Recently completed: Displays work items that belong to the Completed category Recently created: Displays work items created recently 2. You can add new work items from this section. When you click the down arrow, you can see work item types in the drop-down. This drop-down has list of work items available in the current process template. In an Agile process, you can see the following work items: Bug Epic Feature Issue Task Test Case User Story 3. You can navigate to queries by clicking this button. 4. After clicking the column options button, the left-side model pane will open. You can add or remove columns from here. Furthermore, you can change the column order. See Figure 1-24. Figure 1-24 Column options pane 5. You can delete work items, and the recycle bin will contain the deleted items. 6. You can see the view option. This allows you to turn on the button to view completed work items. 7. This allows you to view filters. You will find the following filter options available: Filter by keyword: Filters work items by keywords Types: Filters work items by work item type Assigned to: Filters work items by assigned user State: Filters work items by states Area: Filters work items by area Tags: Filters items by tags 8. You can change the screen size from here. This allows you to move to full-screen mode. Boards You can see the work items in board view here. By default you can see four columns in the board that represent each stage of the work item lifecycle in the Agile process. Let’s identify features on the Boards page. See Figure 1-25. Figure 1-25 Boards page 1. In front of the team name you can see the down arrow to open a drop-down. From this drop-down you can select the teams available in the project and search teams. See Figure 1-26. Figure 1-26 Teams drop-down 2. You can navigate to a backlog view of the work items by clicking this icon. 3. You can open the team settings window by clicking this icon. 4. The velocity chart provides you with the team’s velocity in each sprint, based on the size of backlog items that were completed during a given sprint. For each sprint, a bar is shown in the chart. We will discuss this more in Chapter 6. 5. The cumulative flow chart provides an area graph of the number of work items in each state in a specific time period. We will further discuss this in Chapter 6. 6. You can select different work item types from this drop-down to filter work items on the board. By default you will find the User Story and Feature types only. 7. You can use this view option to turn on the live updates option. If you enable live updates, changes happening to work items elsewhere will be automatically updated in your board. 8. You can add filters to filter work items on the board. The following are the available filter options: are the available filter options: Filter by keyword: Filters using keywords such as part of a work item name Type: Filters by work item type such as Feature Assigned to: Filters the values by giving a team member name Tags: Filters values with tag values Iteration: Filters values belonging to a selected iteration Area: Filters values belonging to each team Parent work item: Filters using a parent work item type 9. You can move to the settings page by clicking this icon. 10. You can move to full-screen mode of the page with this button. 11. You can hide the new column with this arrow. 12. You can hide the closed column with this arrow. 13. You can add a new work item. 14. You can filter the values in the first column only. Backlogs The backlog provides you with the list of backlog items. You can start by adding work items to the backlog. By default, the product backlog level is selected as the backlog level. You can change to portfolio backlog levels using the drop-down in the top right of the Backlogs page. See Figure 1-27. Figure 1-27 Backlog levels The backlog allows you to select a few options to enable different views. See Figure 1-28. Figure 1-28 Viewing options for the backlog 1. This allows you to show the parent hierarchy of the backlog items. When this is on, Forecasting cannot be switched on. 2. Forecasting allows you to forecast how many iterations it would take to deliver the backlog item depending on the work item size take to deliver the backlog item depending on the work item size and the velocity of the team. We will discuss this in later chapters of this book. 3. This setting defines whether to show the In Progress state backlog items in the backlog view. 4. This setting shows the parent portfolio backlog in the side pane. 5. This setting shows iterations in the side pane. This is easier when planning iterations because you can drag items from the backlog to the iterations. 6. You can turn off the side pane. Filter supports filtering work items by a few useful fields or by keyword search, which searches the title of backlog items. See Figure 1- 29. Figure 1-29 Filter backlog Several other useful options are available on the backlog page. Let’s take a quick look at them. See Figure 1-30. Figure 1-30 Options in the backlog page 1. You can add new work items to the backlog. 2. This allows you to select different teams. We will discuss multiple teams in same team project in Chapter 7 of this book. 3. Add the current team to the favorites list. 4. View the Team Settings pane, which pops up on the right side. 5. Switch to the Boards view. 6. Open column options in the side pane of the Backlog view. You can add/remove columns or reorder them by dragging and dropping. 7. Create a query for a backlog. 8. E-mail selected work items from the backlog. 9. Switch backlog view levels. 10. The velocity chart provides you with the team’s velocity in each sprint, based on the size of backlog items that were completed during a given sprint. For each sprint, a bar is shown in the chart. We will discuss this in Chapter 6. 11. The cumulative flow chart provides an area graph of the number of work items in each state over a specific time period. We will discuss this in Chapter 6. 12. These are the view options that we discussed earlier. 13. These are the filters we discussed earlier. 14. Settings of boards. We will discuss this in Chapter 4. 15. Expand the backlog view to full-screen. Sprints The Sprints page allows you to view the previous, current, and future sprints. Let’s take a quick look at the options available in the Sprints page. See Figure 1-31. Figure 1-31 Sprints page options 1. This shows the task board view where stories/ (Product Backlog Items) PBIs/bugs of the sprint/iteration will be shown with the child tasks. 2. This is the backlog view for the sprint/iteration work items. 3. This is the capacity for team members. You can define Activity as the daily capacity of team members and set the days for the individuals or for the team. See Figure 1-32. Figure 1-32 Team capacity 4. You can switch teams when there are multiple teams in the project. 5. You can add the team to the favorites list. 6. Open the team settings side pane. 7. Add new work items to the sprint/iteration. If bugs are set to use at the User Story/PBI/Requirement level, you can add bugs to the sprint as well. See Figure 1-33. We will discuss configuring the bug behavior in Chapter 3. Figure 1-33 Adding an item to the sprint backlog 8. You can select the sprint/iteration to view. 9. This is a shortcut for setting dates for the iteration. 10. The view options (see Figure 1-34) for the Sprints page in the task board view allows you to group tasks by assigned person or by the parent backlog item. The group by options are not available in the Sprints backlog view. The side pane provides two view options. “Work details” shows the capacity versus effort requirements when the capacity for the team is defined and tasks are added with remaining work. We will discuss details about capacity and remaining work in Chapter 2. The Planning option will show current and future sprints, allowing you to drag and drop work items for planning purposes. Figure 1-34 View options on the Sprints page 11. Filter allows you to filter and search work items. 12. This opens the settings for the team in the context of the task board view or sprint backlog. We will discuss these settings in Chapter 4. 13. This allows you to expand to full-screen mode. 14. This is the burndown chart for the sprint. We will discuss this in Chapter 6. 15. This is the backlog work item card in the task board view. 16. This allows you to add child tasks for a given backlog item. Queries Queries are useful for you to view and visualize your work items. You can write simple and complex queries in Azure DevOps. We will discuss queries in depth in Chapter 6. Let’s just take a quick look at what is available on the Queries page for now. See Figure 1-35. Figure 1-35 Queries page 1. Favorites displays queries marked as your favorites or team favorites. 2. This lists all queries. 3. You can start creating a new query. 4. You can create folders to group queries under My Queries or Shared Queries. 5. You can filter queries. 6. The My Queries ones are the only queries available to you. 7. The Shared Queries ones are available to all the members of the team to view. The My Queries list has a few options in the context menu of each query. See Figure 1-36. Figure 1-36 My Queries menu 1. Run the query. 2. Edit the query in the query editor. We will discuss queries in detail in Chapter 6. 3. Rename the query. 4. Delete the query. In the Shared Queries area, a few additional menu options are available. See Figure 1-37. Figure 1-37 Shared Queries menu 1. Add the query to the team’s favorites. 2. Set up security for the shared query. 3. Add a query to the dashboard for visualization purpose. In this lesson, we gave you an overview of Azure Boards and its interface. Lesson 1-5. Customizing Organization Settings There are couple of organization-level settings in Azure DevOps that allow you to set up the behavior of the Azure DevOps organization. Let’s look at the available options in this lesson. You can navigate to an organization’s settings page by clicking “Organization settings” in the Azure DevOps organization home page. See Figure 1-38. Figure 1-38 Getting to the organization settings On the Overview tab you can change the organization name if required. However, this should be done with caution as the URL of the organization gets changed with the name change. A redirection from an old URL will not happen, and users have to manually start using the new URL. This option is there to change the URL from https://orgname.visualstudio.com to https://dev.azure.com/orgname. By default, any new organization uses the new URL pattern. The privacy policy URL can be set to your organization’s data protection and privacy policy documentation URL. Time zone selection for the organization can be updated on the Overview page. The ownership of the organization can be transferred to another user who has access to the organization from the Overview tab. See Figure 1-39. If the organization is no longer required, you can delete the organization as well from the Overview page. Figure 1-39 Overview tab on Organization Settings page The Projects tab lists all the available team projects in the organization. You can rename a team project or delete a team project. Clicking New Project will allow you to create a new team project. See Figure 1-40. Figure 1-40 Projects tab The Users tab will be described in Chapter 8 with security options. The Billing tab lets you set up billing by connecting the Azure DevOps organization with an Azure subscription. See Figure 1-41. When the billing is set up, you are able to add paid extensions to Azure DevOps from the marketplace. We will discuss extensions in Chapter 10. The default available trial extension for test plans can be activated for a 30-day trial from this billing page. Figure 1-41 Billing for Azure DevOps The Auditing tab allows you to view the admin actions audit in the organization. The log can be filtered by a date range and can be downloaded in CSV and JSON formats. See Figure 1-42. Figure 1-42 Auditing Global notifications let you disable organization-level notification subscriptions made by default. With the settings on this page, you can enable delivering notifications to member e-mails as a global policy. See Figure 1-43. This can be overridden at the project level. We will discuss notifications in detail in Chapter 4. Figure 1-43 Global notifications The Usage tab will show the usage of Azure DevOps with several filter capabilities. You can filter for time period, user, and so on, to view usage details. See Figure 1-44. Figure 1-44 Usage We will discuss the Extensions tab in Chapter 10. The Azure Active Directory tab lets you associate an Azure DevOps organization with your company’s Azure Active Directory. If your organization has been created with an organization user, then it will be automatically linked with the organization’s Azure Active Directory. However, you can associate an Azure DevOps organization that is created with a Microsoft account to a company Azure Active Directory. Before associating, you need to transfer the ownership of the Azure DevOps organization to a user from the company who has access to the Azure Active Directory of the company. For further information on how to do this, you can refer to http://chamindac.blogspot.com/2019/05/join- personal-azure-devops-organization.html. We will discuss security policies and permissions at the Azure DevOps organization level in Chapter 8 of this book. Other organization settings will be covered in the relevant books of the series. For example, agent pools will be covered in the Hands-on Azure Pipelines book. In this lesson, we discussed a few organization-level settings that are useful to set up the behavior of the Azure DevOps organization. Lesson 1-6. Previewing Features and Themes The Azure DevOps services often get released with preview features. You can enable such features for yourself or can enable some of these features for your organization. Additionally, you can opt to use the Light or Dark theme in Azure DevOps. Let’s look at how to set up these options. Clicking your profile avatar at the top left of Azure DevOps will show a menu. In this menu you can click “’Preview features” to see any available preview features. The Theme menu item can be used to open the theme settings. See Figure 1-45. Figure 1-45 Preview features and themes Once you click “Preview features,” a pane will open where you can enable or disable preview features for your account or for the organization. See Figure 1-46. Figure 1-46 Preview features In the theme settings, you can select one of the available themes, and it will be applied to you. See Figure 1-47. Figure 1-47 Themes In this lesson, you learned how to enable preview features and changed themes based on your preferences. Summary In this chapter, you explored how to get started by creating an Azure DevOps organization. We explained how to create team projects with different templates and compared the process models/templates to give you an understanding of the capabilities of Azure Boards in supporting typical software development process models such as Agile, Scrum, and CMMI. In addition, we discussed the Basic process model so as to help your team to get started in the simplest way possible with Azure Boards. Further, we discussed how to customize the organization settings, how to enable and disable preview features, and how to use themes. We gave you a quick overview of all the areas available in Azure Boards and in the Overview section. You now have an overall understanding of Boards for diving deep into each area in the coming chapters. In the next chapter, we will discuss how to set up a team project in a simple way to get you started with Azure Boards in the context of a small team. © Chaminda Chandrasekara and Pushpa Herath 2019 C. Chandrasekara, P. Herath, Hands-on Azure Boards https://doi.org/10.1007/978-1-4842-5046-4_2 2. Setting Up a Team Project Chaminda Chandrasekara1 and Pushpa Herath2 (1) Dedigamuwa, Sri Lanka (2) Hanguranketha, Sri Lanka Lesson 2-1. Creating a Team Lesson 2-2. Defining Common Project Settings Project Settings General Project Settings Boards Settings Lesson 2-3. Setting Up Areas Project Areas Team Areas Lesson 2-4. Setting Up Releases and Iterations Team Project Iterations Team Iterations Lesson 2-5. Setting Up Team Members and Permissions Lesson 2-6. Defining Team Capacity and Days Off Summary The objective of this chapter is to help you create an Azure DevOps project and use Azure Boards to plan and deliver work. The initial preparation involves adding team members, setting up areas and iterations, and planning team capacity. By the end of this chapter, you will have a thorough understanding of the initial setup requirements in a team project of Azure Boards. Lesson 2-1. Creating a Team As the starting point, let’s look at how to create a new team in a team project. We covered how to set up a new team project in the previous chapter. Prerequisites: You need to have a Microsoft account and a new Azure DevOps team project in an Azure DevOps organization where you are the administrator. In an Azure DevOps project, you can create a new team in the Settings section. Go to the project settings and then select Teams in the General section. You will see the “New team” link. Click the link to add a new team. See Figure 2-1. In addition, you will be able to see the existing teams in this Teams section. Figure 2-1 Adding a new team using the project settings After clicking the “New team” link, you will see a pop-up menu that allows you to create a new team. Let’s identify each section of the pop- up. See Figure 2-2. Figure 2-2 Pop-up for creating a new team 1. Name the team. 2. Add a description of the team. 3. You can add the team to any existing security groups in this drop- down. Then members of this team will get the same permission as the selected group. See Figure 2-3. Figure 2-3 Selecting a security group to add team permissions 4. If you want to create an area path with the team name, you can select this check box; otherwise, you can create a team without an area path. There may be situations where you need to add a team to an existing area path or to the root area path. So, you can deselect the check box and create a team without an area path but with a team name. 5. You can move to the Settings tab. You can add team administrators in this Settings section. After moving to the Settings tab, you will see the existing team administrators and also an Add link to add new team administrators. See Figure 2-4. Figure 2-4 Adding new team administrators After doing this, click the Add link, and a new pop-up will open. You can add administrators using this pop-up. You will be able to see the Identities drop-down list. You can select the project members from this drop-down who are going to become administrators of the new team. See Figure 2-5. Also, you can add new users who are not currently known to Azure DevOps services. After entering the sign-in address of a new user, you can click “Check name” to verify the validity of the entered name. After selecting or entering a team member, click “Save changes” to add the selected member as an administrator. Figure 2-5 Selecting an existing project member as an administrator If you click the Browse link, you can search and select existing project members to be administrators. See Figure 2-6. After selecting the members, you can click the Add button to add the selected members as administrators. Figure 2-6 Searching for team members 6. Click the “Create team” button to create a team. 7. Click the Cancel button to cancel the creation of the team. After creating a new team, you will be able to see the team in the Teams section of the Project Settings page. See Figure 2-7. Figure 2-7 Newly created team In this lesson, you learned how to create a new team in an Azure DevOps project. You also understand that you can add multiple teams according to your project requirements. Lesson 2-2. Defining Common Project Settings Let’s take a look at all the project settings in this lesson, while getting a detailed understanding of the sections not covered already in previous lessons. Project Settings To view the project settings, you can click “Project settings” (Figure 2- 8) at the bottom left of the team project page. The Project Settings section has multiple areas. Figure 2-8 Project Settings 1. Navigate to the Project Settings section. 2. This area contains general settings. 3. This area contains settings related to Azure Boards. 4. This area contains settings related to Azure pipelines. 5. This area contains settings related to Azure repos. 6. This area contains settings related to testing. Let’s take a look at the General and Boards sections as they are related to Azure Boards. The other sections will be discussed in the next relevant books of the series. General Project Settings The General project settings are the common settings for a team project. This area has a few subsections. See Figure 2-9. Figure 2-9 General settings 1. Overview: This section contains settings such as the project name and project visibility options to enable or disable Azure DevOps services for the project. We covered this section in detail in Chapter 1. 2. Teams: This section contains a list of teams available in the team project. You can create a new team by clicking “New team.” Each team has a context menu that allows you to set the team as the default team of the team project or delete the default setting, if it is not the default one anymore. See Figure 2-10. Figure 2-10 Teams section 3. Security: The security settings of the team project can be defined here. We will further discuss this in Chapter 8. 4. Notifications: This section lets you subscribe to notifications generated by Azure DevOps based on events that occur on work items, builds, and so on. See Figure 2-11. Figure 2-11 Notifications A. Allows you to create a new subscription for a notification/alert. Select the category of the alert and use the available template to set up the notification. See Figure 2-12. Figure 2-12 New subscription When you click Next, you will be able to add filter criteria for the notification and subscribe. We will discuss subscribing to a notification in Chapter 3. B. The “Delivery setting” section lets you set the preferences of notification delivery for a given team. You can set up y g p notifications to be delivered to a fixed e-mail address, deliver them to individual team members, or not deliver them at all. See Figure 2-13. Figure 2-13 “Delivery settings” section C. Help will take you to the Microsoft documentation on notifications. D. You can expand the interface to full-screen mode. E. This shows that a subscription for an alert is a default one. These cannot be edited. However, they can be disabled, as shown in F. F. You can enable or disable subscriptions. G. This opens the subscription context menu. H. You can view the default subscription details. Edit and delete options will be available for the custom subscriptions created. I. You can select a team for the team project. 5. Service hooks: These can be created for many services such as Microsoft Teams to allow you to notify those services based on an Microsoft Teams to allow you to notify those services based on an event in Azure DevOps. You can get notified at your own web URL as well. For that you can select Web Hooks in the dialog that appears after clicking “Create subscription” in the Service Hooks section. See Figure 2-14. Figure 2-14 Setting up service hooks You can select from the many events available such as work item created, build completed, and so on. See Figure 2-15. Figure 2-15 Service hook trigger Then you can provide the URL you want to post the event to, and any authentication information as well can be included to authorize posting to the URL. You can also filter the information sent and define the format for a web hook. For more information, refer to https://docs.microsoft.com/en- us/azure/devops/service- hooks/services/webhooks?view=azure-devops. hooks/services/webhooks?view azure devops. 6. Dashboard: This section lets you define the permission for team members to create, edit, and delete dashboards. Only a team administrator or higher-level user such as project admin or collection admin can change these settings. See Figure 2-16. Figure 2-16 Dashboard permissions Boards Settings In the Boards settings, you can define iterations, areas at the team project level, and areas and iterations for a given team. In addition, there are a few common settings that can be set in the Boards section. Let’s identify the subsections under Boards first. See Figure 2-17. Figure 2-17 Boards settings 1. Project configuration: This section allows you to define areas and iterations for the team project. We’ll discuss these in detail in the next two lessons of the chapter. 2. Team configuration: You are allowed to select team iterations and areas and a few other settings for a selected team here. Let’s look at team settings that you can set in this section. 3. GitHub connections: This allows you to set up a connection so that you can work with Azure Boards while integrated into GitHub repos. We will discuss this further in Chapter 10. Team Configuration General Tab On this tab, you can set general settings by selecting a team in the team project. See Figure 2-18. Figure 2-18 Team settings, General tab A. Select a team. B. Select the backlog levels for the team. C. Define the workdays for the team. D. Define how a bug work item should be used in the team. The options are to manage bugs in the same level with requirements/user stories/product backlog items, manage bugs with tasks, or not to show Bug work items in boards. We will discuss this in Chapter 3. We will skip discussing the Iterations and Areas tabs as we will have separate lessons for them in this chapter. Team Configuration Templates Tab The Template tab allows you to create templates for work items in a selected team. Using the Template link, you can create new work items with predefined values as defined in the template. See Figure 2-19. Figure 2-19 Team settings, Templates A. Select the team. B. Select the work item. C. Create a new template. D. This is the context menu of the template. E. Edit the template. F. Delete the template. G. Copy the link to create a work item with the template. H. Create a copy of the template and open up a new template create dialog with the selected template values. In the new template create/edit template dialog, you can define a name and description for the template. You can select multiple fields and set values for them for the template in this dialog. Further, you can provide a comment that will be added as a discussion comment when the work item is created via the template-provided link. See Figure 2- 20. Figure 2-20 Editing the template You can copy the link and use it in any browser or application. The link will take you to the relevant work item create page with values from the template filled in automatically. See Figure 2-21. Figure 2-21 Creating a work item with template 4. We will discuss GitHub connections in Chapter 10. In this lesson, you looked at the common general and board-related settings. These settings are important to get you started working with Azure Boards. Lesson 2-3. Setting Up Areas The area path in Azure DevOps helps you to modularize your work by grouping work items by product, feature, or business area. A new project will have a single root area corresponding to the project name as well as the default team that is created when a new team project is created. Project Areas To find the list of area paths available in the project, select “Project settings,” select “Project configuration,” and then select the Areas tab. You will be able to see all the available area paths of the project. See Figure 2-22. Figure 2-22 Area path section of project settings You will be able to see the root area and all the added areas as child areas. You can add new child areas in this section. See Figure 2-23. Figure 2-23 Areas list 1. When you select the subarea, this link will be enabled. It allows you to add another area in the same level as the selected item. 2. You can add a child item to a selected item. 3. You can expand one level. 4. You can collapse one level. You can add new items using options in the pane that opens when click the three dots in front of the existing area name. See Figure 2-24. Figure 2-24 Selected project area context menu If you click the three dots in front of the root item, you will be able to see that the “New child” and Security items are the only items enabled. Let’s identify each option in the pane. 1. Add a new item to the same level as the selected item. Click New, and a pop-up will open. You can name the new area path, and the default location is the root area. See Figure 2-25. Figure 2-25 Adding a new area path 2. Add a new child item to the selected item. After clicking this link, you will be able to see a pop-up similar to Figure 2-25. 3. Click Edit to edit the name of the area path and change the parent item of the area path. After you click Edit, pop-up will open. It allows you to change the area path name and location. See Figure 2- 26. Figure 2-26 Editing the area name and location 4. You can delete the area by clicking Delete. If you click Delete, you will see a pop-up message. You can delete an area by clicking the “Delete path” button in the pop-up, and any existing work item will be moved to the reassignment path selected, as shown in Figure 2- 27. Figure 2-27 Deleting an area 5. You can control the permission of a given area using this option. When you click Security in the context menu, a security pop-up will open, which allows you to control the area permissions. See Figure 2-28. Figure 2-28 Area security Now that you have configured the area path for a project level, let’s explore the team-level area path settings. Team Areas A team can select a subset of areas defined in the team project. An area can be shared with multiple projects, and it is possible to use separate area paths to isolate the work items of a team from another team in the same team project. Click Project Settings, expand Boards, and click Team Configurations. Then click the Areas tab to view the team’s Area settings. See Figure 2-29. Figure 2-29 Team areas 1. You can select a team in the team project. 2. It is possible to change the default area of the team. The default area of the team determines to which area path a newly created work item’s Area path field is set, when created in the context of the team. 3. Select the area for the team using the pop-up that opens. It is possible to select multiple areas at once using the +Area button. You can check the Include subareas to make work items belong to the selected areas and all child areas of the selected areas and make them visible to the team Removing a selected area before saving is them visible to the team. Removing a selected area before saving is possible via the X in the right corner of the selected area path. See Figure 2-30. Figure 2-30 Selecting areas for the team 4. Remove a selected area. 5. Create a new area at the same level of the selected area. When you add areas from a team, they will be available at the team project level as well. 6. Create a child area for the selected area. 7. The default area of the team is autoselected as a selected area. 8. This loads the context menu of a given selected area. See Figure 2- 31. Figure 2-31 Selected team area context menu A. You can create a new area at the same level of the selected area. B. You can create a new child area for the selected area. C. You can edit the selected area. D. You can remove the selected area from the team. E. You can open the permissions dialog for the selected area path where you can set permissions. F. You can set the selected area as the default area for the team. G. You can include the subareas of the selected area so that the work items of the selected area and all the subareas of the selected area are visible to the team. In this lesson, you explored the area path configuration at the team project and team levels. This knowledge will help you to group your work items based on business needs. Lesson 2-4. Setting Up Releases and Iterations The iteration path allows you to group work items based on timebox intervals, such as sprints or iterations. Similar to the area paths, the iteration paths can be defined at the project level, and teams can use them as shared or as isolated iterations. This lesson will explain how to set up iterations on the project level and use them on the team level. Team Project Iterations Let’s try to add new iterations to the Azure DevOps project from the team project’s Settings page. Click “Project settings” and then select “Project configuration” in the Boards section. Then you will be able to see the Iterations tab. Select the Iterations tab, and you will see the default set of iterations in the Azure DevOps team project. See Figure 2-32. Figure 2-32 Team project iterations You will find an iteration with a name similar to the project name and child iterations of it. It is possible to add new child iterations from here. If you click the root iteration (TheDarkKnight in Figure 2-32), you will see a grayed-out New link. When you click a child item, it becomes clickable. This behavior is because you cannot create the same level of iteration in the root iteration level. You can add a new iteration at the same level using the New link in any child-level iteration. To add a child iteration to any selected iteration, use the “New child” link. See Figure 2-33. Figure 2-33 Iteration toolbar 1. Add a new item to the same level as the selected item. 2. Add a new child item to the selected item. 3. Expand one level. 4. Collapse one level. Let’s add a new iteration at the same level of Iteration 1 with the New link. Select Iteration 1 and click the New link. A pop-up window will appear, which allows you to create a new iteration by giving the iteration name, the start date of the iteration, and the end date of the iteration. See Figure 2-34. You can keep the start date and end date blank and set them later if required. Figure 2-34 New iteration If you try to add a new child iteration to Iteration 1, you will be able to see the same pop-up. The only difference is that the location will be TheDarkKnight\Iteration1. Besides using the previously mentioned New and “New child” links, you can add new iterations with the context menu that opens when you click the three dots next to each iteration. See Figure 2-35. Figure 2-35 Iteration context menu 1. Add a new iteration to the same level as the selected iteration. 2. Add a new child iteration to the selected iteration. 3. You can edit the iteration values using this option. After clicking the edit button, a pop-up will appear, and you will be able to edit the iteration name, start date, end date, and location from the pop-up dialog. See Figure 2-36. Figure 2-36 Editing an iteration 4. Delete the selected iteration with the Delete option. After you click Delete, you will see the pop-up where you can select a path to reassign the work items if any belong to the deleted iteration. See Figure 2-37. Figure 2-37 Deleting an iteration 5. You can control the security of the iteration using this option. After clicking this security menu item, a pop-up will appear. You can control the iteration permission from this pop-up. See Figure 2-38. Figure 2-38 Iteration permission So far, you have learned how to add iterations to the Azure DevOps project. Now, you’ll learn how to use iterations when you have multiple teams for the project. Team Iterations Go to the project settings and then select Teams under General. You will see a list of teams available in the team project. See Figure 2-39. Figure 2-39 Teams Now click one of the required teams. The team profile will open. Click the “Iterations and areas” link under the “Manage other settings for this team” item. See Figure 2-40. This will navigate you to the team configuration values of the selected team. Click the Iterations tab. Figure 2-40 Team profile Instead of navigating through that path, you can click “Project settings” and then click “Team configuration” under Boards. Then can click the Iterations tab and select the required team from the drop- down at the top of the page. See Figure 2-41. Figure 2-41 Team iterations 1. You can find the default iteration of the team here. The default iteration of a team determines the iteration a new work item is getting added to when it is created within the team context. Dev Team in this example has the selected current iteration as the default iteration. That means when you add a new work item, it is getting added to the current iteration. 2. You can change the backlog iteration of the team from here. The backlog iteration determines which work items are shown in the team’s backlog and boards. You can change these backlog iteration values by using the Change link. After clicking the Change link, select iterations from the drop down and click Set to save the select iterations from the drop-down and click Set to save the selected value or click Cancel to dismiss the changes. See Figure 2- 42. Figure 2-42 Changing the backlog iteration 3. You can add the iterations to the team. In Figure 2-43, you can see there is no iteration selected for the team. You can click the “Select iterations” link and add the iterations to the team. See Figure 2-43. Figure 2-43 Selecting an iteration for the team After an iteration is added, the team will be able to work with iterations/sprints. Also, you will see that a context menu is available for a selected iteration, with the same actions that we discussed in the selected iterations of the team project. See Figure 2-44. Figure 2-44 Selected iteration context menu Since iterations are hierarchical in structure, and you can define timeboxes with practical needs such as grouping multiple iterations into one release iteration. This is against the Agile methodology, which is all about delivering a shippable product in every sprint/iteration. However, in the practical world, even though you might have shippable product each iteration, shipping to the actual client may happen after a couple of iterations. An example setup looks like Figure 2-45. Figure 2-45 Release and iterations In this lesson, you explored how to set up iterations in a team project and use them in a team. As mentioned earlier, iterations can be shared or used in isolation in a given team. Lesson 2-5. Setting Up Team Members and Permissions A team should have team members to perform work. This lesson will describe how you add new team members to the team. You can add members individually or as groups. First let’s identify the default groups available in the Azure DevOps team project and the permissions of each group. Go to the project settings and select Security in the General section. You will be navigated to the Security area where you can control the permissions of team members and groups. See Figure 2-46. Figure 2-46 Team project security Let’s identify the basic capabilities of the security settings in this lesson; you will learn more about security in Chapter 8 of this book. See Figure 2-47. Figure 2-47 Team project permissions 1. Create a new group using this link. Clicking this link will open up a dialog. You will be able to add new group details using the pop-up window. See Figure 2-48. Figure 2-48 Creating a new security group 2. You can filter users and groups. 3. You can display all the teams available in the Azure DevOps project. 4. You can display all the groups available in the Azure DevOps project. 5. The Permission tab displays all the permissions of the selected team or group. 6. The Members tab displays the members of the selected team or group. 7. You can edit or delete the selected team or group. Now you have a basic idea of groups in an Azure DevOps team project; let’s move to the team settings of the Azure DevOps project and see how to set permissions there. Go to the project settings, select Teams, and select the name of a specific team from the team list. You will be navigated to the team profile. Click the Add button to add new members. See Figure 2-49. Figure 2-49 Adding a member to a team A pop-up will appear that allows you to add new team members. You can add members by providing sign-in addresses or group aliases. See Figure 2-50. Figure 2-50 Adding a new member or group In addition, you can add team administrators from the team profile. Click the Add button, and a pop-up will appear. See Figure 2-51. Figure 2-51 Adding a team administrator Add an individual member or group as the team administrator using the pop-up. We discussed team permission settings in this lesson. You learned how to add individual members and groups as team members. Additionally, we discussed how to add administrators to the team. Lesson 2-6. Defining Team Capacity and Days Off We defined iterations in a previous lesson. In iterations, you can define the team’s capacity in order to allow you to find the available capacity for each activity type within the team. This will enhance the team’s ability to commit to completing an iteration and give you an idea of whether the team can meet the commitments made. Select the Sprints/Iterations menu item from the side menu under Boards. Select the team that you need to define the capacity for from the drop-down. Then move to the Capacity tab. See Figure 2-52. Figure 2-52 Team capacity 1. Select the team. Next to this drop-down you can click the star icon to add the team to the favorites list, and you can click the people icon to see the team profile. 2. You can select the Capacity tab here. 3. You can add a team member to the capacity planning. 4. You can save the capacity plan. 5. You can undo a change made to the capacity plan before saving. 6. You can add all the team members and copy the capacity planning of the previous sprint/iteration to the current/future one. See Figure 2-53. Figure 2-53 Team capacity context menu 7. You can select the sprint/iteration. 8. You can show/hide work details in the side pane. See Figure 2-54. Figure 2-54 Configuring the side pane 9. You can open the Settings page, which we will discuss in the next chapters. 10. You can go to full-screen view. 11. You can define individual days off. You can add multiple periods of days off and remove added days off by clicking the X to the right of the days off. See Figure 2-55. Figure 2-55 Individual days off 12. You can define team days off applicable to all members of the team. 13. You can add another activity type from the available list to a given member and set capacity. You can remove the user or one of the activity types for a user as well. See Figure 2-56. Figure 2-56 Team days off 14. You can view the work details in the side pane. We will discuss this pane in Chapter 3 where the work estimation is described with work items assigned to a given sprint. 15. You can view the work capacity and assignments by activity. 16. You can view the work capacity and assignment by team member. In this lesson, you explored how to set up the team capacity for the team members for a given iteration. We will discuss team capacity and work estimations more in the next chapters. Summary In this chapter, you explored how to create teams in a team project and use general and Azure Boards–related settings. Further, we discussed how to set up areas, iterations, and team capacity. This will enable you to get started with Azure DevOps Boards and follow the next lessons in this book. In the next chapter, you will learn about setting up boards and work items and using boards to work with work items. © Chaminda Chandrasekara and Pushpa Herath 2019 C. Chandrasekara, P. Herath, Hands-on Azure Boards https://doi.org/10.1007/978-1-4842-5046-4_3 3. Working with Backlogs and Boards Chaminda Chandrasekara1 and Pushpa Herath2 (1) Dedigamuwa, Sri Lanka (2) Hanguranketha, Sri Lanka Lesson 3-1. Understanding the Backlog Hierarchy Lesson 3-2. Defining a Backlog Organizing Epics in a Hierarchy Adding Features to Epics Adding Stories to Features Adding Tasks to User Stories Changing the Parent Using the Work Item Context Menu in the Backlog View Lesson 3-3. Exploring Important Work Item Fields Common Important Work Item Fields Lesson 3-4. Selecting Work to Move to an Iteration Lesson 3-5. Using Kanban Boards and Task Boards Kanban Boards Task Boards Lesson 3-6. Working with a Bug Work Item Managing Bugs with Tasks Managing Bugs with Requirements Bugs Not Managed with Requirements or Tasks Summary Keeping track of the work that your team does is important so you can make process improvements to your team’s way of working and increase productivity. The work of your team can be captured as work items in Azure DevOps, and you can use various boards and backlogs to organize and plan the work items. In this chapter, we’ll cover the options you have in Azure Boards to organize your work hierarchically, to plan the work process using Kanban, and to use iterations to plan for time-based cycles of work. We will also discuss the available features to successfully run your project teams with Agile/Scrum or with traditional processes, including the options you have to handle software bugs discovered during the development and testing processes or in production. Prerequisites: It is essential that you have worked through the first two chapters of this book so that you have the required basic understanding to successfully follow the lessons in this chapter. Lesson 3-1. Understanding the Backlog Hierarchy Azure DevOps allows you to create a hierarchy in the backlog to group work according to business needs. By default, two levels of backlogs are enabled in an Azure DevOps team, as explained in Lesson 2-2. They are the feature for all three templates Agile, Scrum and CMMI and user story for Agile workflows, the product backlog item in Scrum, or the requirement in CMMI. Lesson 2-2 also explains how to enable a top backlog level of Epic. There is another way to enable or disable backlog levels for a team. In a team’s backlog or board view, you can open the Settings pop-up by clicking the cogwheel icon just below the cumulative flow diagram, at the top right of the page. In the General section of the Settings pop-up, you can enable or disable the backlog levels to be used in your team on the Backlogs tab. See Figure 3-1. Select the Epics, Features, and Stories levels for this lesson. Figure 3-1 Selecting backlog levels To understand the backlog levels, let’s look at a common business example such as a banking system. When implementing the banking system, there could be a broad requirement of “A need to have a banking system to manage savings and lending accounts.” This requirement could be broken into two levels: “A need for savings account management facility” and “A need to manage leading accounts such as personal and vehicle loans.” You could use the Epics level to manage these three requirements with a parent-child hierarchy. (You will learn how to create work items in that manner in Lesson 3-2.) Then if you take the loans section, there could be several features such as “Capture new customer and loan requirement details,” “Review process of loan application and approval,” and so on. You can use the Features backlog level to keep the backlog organized into features as child requirements of the Epics level defined previously. (You will learn how to do this in Lesson 3-2 of this chapter.) To implement each of these features, you might need several stories, and each story may need a couple of tasks to get it implemented. The user stories (Agile)/product backlog items (Scrum)/requirements (CMMI) can be created as child work items of the relevant feature work item. It is even possible to create multiple levels within a work item type. However, keeping the story/PBI/requirement level as a flat level without creating a hierarchy is recommended. One reason for this recommendation is to keep the estimates of size and effort from getting too large in Azure DevOps; you will learn about this in Lesson 3-3. In addition, a story in the Agile process should be an independent testable unit of work, which should not include any dependencies other than the set of tasks needed to implement that story. The tasks should be the child items of a user story work item. See Figure 3-2. Figure 3-2 Banking system sample backlog We used a banking application as an example in this lesson to explain how to use the backlog hierarchy. Lesson 3-2. Defining a Backlog In this lesson, you’ll learn how to create a backlog of work and add it to your team project and teams, which will allow you to extend the understanding you have gained in the previous chapter. Prerequisites: You need to work through Chapters 1 and 2 and have familiarity with the navigation of and various options available in Azure Boards. You also need to have worked through Lesson 3-1. You have a team project created in Azure DevOps with the Agile template for your team, and you have enabled the Epics, Features, and Stories backlog levels. Organizing Epics in a Hierarchy You can create a backlog of work items in the Work Items, Boards, or Backlogs page in Azure Boards. Let’s use the Backlogs page so you can define your backlog hierarchically. Click Backlogs, and in the “Backlog work item type” selection drop-down, select Epics. Click the New Work Item button in the middle of the page or in the toolbar, and you will be able to provide the title of the first epic. Enter As banker I need a banking application to maintain customer savings accounts and lending facilities as the title in the text box, as shown in Figure 3-3, and click the “Add to top” button. Since this is the first work item, adding it to the top, adding it at the selection, and adding it to bottom will all have the same effect. Figure 3-3 Creating the first Epic work item You can click the title of the first epic to view its details. In the epic form/page, inspect the iteration path and area path set by default. As discussed in Chapter 2, you can set the team preference to Default Iteration and Default Area in the Team Configurations page, which the iteration and area will be set automatically for any work item that is created in the context of the team. Once the first epic is added, you can add a child Feature work item to it by clicking the + sign next to the epic in the backlog. See Figure 3-4. Figure 3-4 Adding a child Feature work item to the Epic work item However, before adding features, you need to add child epics because you are going to use two epic levels parent and child to group the requirements. Tip You can add more backlog levels to avoid creating a parent- child relationship within the same work item type. You’ll explore how to add more backlog levels while customizing the process templates. To add another epic level as a child to an existing Epic work item for the first time, you have to use the “Add link” option in the parent’s Epic work item form. Open the epic you just created by clicking the title of it. In the work item form, you will see a section named Related Work. Here when you click “Add link,” you will be able to link another work item to the current work item, with one of the predefined sets of relationships. Since you have not created the second-level epic yet, click “New item.” See Figure 3-5. Figure 3-5 Adding a new work item as related work Set “Link type” to Child and “Work item type” to Epic. Then enter the title As a banker I need saving account managing facility and click OK to create the new child epic under the current Epic work item. See Figure 3-6. Then save and close the work item form to save the child-parent link between the two work items. Figure 3-6 Adding a child epic to create two levels of Epic work items Before proceeding, let’s discuss the available relationships between work items in brief. Child-Parent: This relationship is used to organize work items in a hierarchy using one-to-many relationships. Affects-Affected By (CMMI only): This is used to track the change requests for requirements. Duplicate-Duplicate of: This allows you to define that a work item is a duplicate of another. It is especially useful when you want to add multiple parent work items to a work item, because the duplicate work item can be linked to a different parent work item (only one parent is allowed for any work item in Azure DevOps). Reference By-References: This is used to link test cases to shared parameters, enabling a repeat of a test with different data. We will discuss this further in the Hands-on Azure Test book in this series. Related: This is used to identify the relationship between work items in the same level. Successor-Predecessor: This link is used to identify dependencies between work items. It is especially useful to identify a task that should be completed before starting another task work item. Tested By-Tests : This is a link between test cases and work items such as user stories, features, or epics. Test Case-Shared Steps: This is used to share common steps between multiple test cases. We will discuss this further in the Hands-on Azure Test book of this series. Note For further information on work item link types, refer to https://docs.microsoft.com/en- us/azure/devops/boards/queries/link-type- reference?view=azure-devops#work-link-types. Now that you have added a child epic for the savings account area in banking under the main banking system epic, you should be able to see that a hierarchical backlog is available within the same work item type in the epic backlog view. It is possible to create this type of hierarchy within any backlog level available; however, as previously mentioned, it is advisable to keep the Stories level as a flat level. To add another epic in the backlog view, click “New Work item” and enter the title As banker I need lending facility to enable granting personal. Click “Add to bottom.” This will add a new Epic work item, but not as a child work item of the main banking system epic. To add this third epic to the first epic as a child, open the work item form of the first epic and click “Add link” in the Related Work section. Then click Existing Item to open the pop-up for adding a link to an existing work item (see Figure 3-5). You can search for the third epic by typing in part of the title or the ID of the work item and then select the correct one from the list that appears. See Figure 3-7. Then save and close the work item form to save the child-parent link between the two work items. Figure 3-7 Adding an existing work item as a child link Using either of the previously described procedures, add another child epic with the title “As banker I need lending facility to enable granting vehicle loans” to the banking system’s main epic. See Figure 3- 8. Figure 3-8 Hierarchical epics Instead of opening the work item form and trying to add the link, you can add a link to any work item using a context menu. See Figure 3- 9. Figure 3-9 Adding a link to a work item via a context menu You have created subepics for a sample banking system and grouped them as children under a parent to create a hierarchy under the main banking system epic. You can use the Boards view of the epic as well to add child features to a given epic, which we will discuss in Lesson 3-5. Adding Features to Epics Now that you have three major epics as requirements of the sample banking application, let’s move on to identify how you can create features under these epics. To create new features, you can switch to the feature backlog view by selecting Features in the drop-down at the top right of the Backlogs page. However, if you add features in this manner, you have to manually create the child-parent link with the required epics. Hence, let’s stay in the epic backlog view and add features to each epic from the Epics view by clicking the + sign to the right of each epic. Once you click the + sign, a new feature work item form will open and have a parent link with the relevant epic. See Figure 3-10. Provide a feature with the title “Facilitate customers to open savings accounts” and save the feature. Figure 3-10 Adding a child feature to an epic Now add a couple more features to the epic such as “Facilitate savings cash deposit over the counter” and “Facilitate savings cash withdrawal over the counter.” You could even go ahead and create another child at the Features level under the saving accounts epic such as enabling ATM transactions, or you could add a child feature level, as we discussed earlier. Adding Stories to Features Now that you have epics and features of the sample application organized into a hierarchical grouping, let’s add user stories to implement each feature. Again, you can move to the user story backlog view using the drop-down in the Backlogs view page to add new user stories. However, it is recommended that you use the feature or epic backlog view and add the required child stories to Feature work items using the + sign right to each feature (see Figure 3-11) or the context menu of each feature. Or you can use feature board view to add child user stories to Feature work items, which we will discuss in Lesson 3-5. Figure 3-11 Adding a child user story to a feature Add a couple of user stories to the relevant features. For example, you can add “Facilitate customers to open savings accounts” with user stories such as the following: “As a banking officer, I need to capture customer details so that a new customer can be added to the bank” “As a banking officer, I need to open a savings account for a customer” “As a banking officer, I need to perform initial cash deposit for a new savings account so that the account to get activated” See Figure 3-12. Figure 3-12 Stories added to a feature Add a couple more features and user stories to fully understand how the child-parent relationship can be used to hierarchically organize the backlog. Adding Tasks to User Stories To implement user stories/product backlog items/requirements, you can define tasks. To add tasks to a given user story, you can use the user story backlog view or even the epic backlog view. In either view, you can click the + sign to the right of the user story (see Figure 3-13) or use the context menu to select “Add link” and then “New item.” Figure 3-13 Adding tasks to a user story Add a couple of tasks for each user story so you can see how it looks and understand how it works in the backlog view. Changing the Parent You can change the parent of any backlog item except the topmost backlog level (as of now the epic is the topmost backlog level) by using that work item’s context menu and selecting “Change parent.” See Figure 3-14. You can select multiple work items of the same type and change the parent. Figure 3-14 Changing a parent A pop-up window will allow you to select immediate top level a work item from backlog items, which you can reparent the work item to. See Figure 3-15. Figure 3-15 Changing the parent pop-up Additionally, you can use drag and drop in the backlog view to change the parent of a given work item. You can select multiple work items of the same type and change the parent. See Figure 3-16. Figure 3-16 Dragging and dropping to change the parent Using the Work Item Context Menu in the Backlog View You have already used a couple of options in the work item context menu. Let’s explore each available menu action to make sure you understand all of them. See Figure 3-17. Figure 3-17 Work item context menu in backlog view 1. Selecting Edit will open a dialog that will allow you to edit work item fields selectively. You can select multiple work items from different types and perform bulk edits on all selected work items using this option. You are allowed to add a note while you make the edit to the fields, which will appear in the history of each work item edited. See Figure 3-18. Figure 3-18 Editing work item fields 2. “Assign to” will allow you to assign selected work items to a user all at once. 3. “Copy to clipboard” lets you copy the selected work item’s visible columns in the backlog view to the clipboard. When you paste in Word, Excel and so on, in addition to the data, you get a link to a temporary query where you can navigate to a query view of the selected work items. 4. Delete allows you to move work items to the Recycle Bin, which can be found via the Work Items page of Azure Boards. A message will pop up to confirm the delete. From the recycle bin you can restore the deleted work items or permanently delete them. 5. Template allows you to capture a template from a single work item; we discussed the usage of templates in Lesson 2-2. 6. “Add link” lets you add the linked work items as we have been discussing throughout this lesson. 7. “Move to iteration” allows you to move selected work items to a 8. given iteration. “Change parent” lets you change the parent work item of selected work items as we have been discussing in this lesson. 9. “Move to position” lets you move work items in the order of the backlog. It’s especially useful when you have a longer backlog and when you want to move an item at the bottom to the top or near to the top. 10. “Change type” lets you change the type of work item for selected work items. For example, you might have created a set of items as user stories, but you may want to make them features instead of stories. You can use this option and easily change the work item type without having to re-create each work item. 11. You can move selected work items to a different team project in your Azure DevOps organization. You are able to select the target team project, area path, or iteration path, and you can even change the work item type during the move. 12. You can e-mail selected work items to the required team members. See Figure 3-19. Figure 3-19 E-mailing work items 13. “New branch creation” allows you to create an Azure Git repo b h hi h ill di i h H d A R b k branch, which we will discuss in the Hands-on Azure Repos book of the series. 14. “Do exploratory testing” lets you explore the system based on the work item implementation and record test cases. We will discuss more about this in the Hands-on Azure Tests book of the series. In this lesson, we discussed how to organize a backlog hierarchically using the backlog view of Azure Boards. Lesson 3-3. Exploring Important Work Item Fields You created a couple of work items of different types in the previous lesson, so it is good time to explore some important fields of a given work item. Common Important Work Item Fields Let’s take a look at common and important work item fields available for all the work item types. Id: This is a unique ID for each work item across all projects in a project collection/Azure DevOps organization. Title: This is a short description of the work item. Description: You can provide in-depth information about the work item here. Acceptance Criteria: This is available in the Scrum template for the Epic, Feature, PBI, and Bug work items. It is useful to define the criteria for allowing the work item to evaluate for its completion with the Acceptance Critera before closing it. Repro Steps: You can write the bug-reproducing steps in this field. This is available in a Bug work item. Area Path: This is the team area or module of the work item. Iteration Path: This is the path of the iteration in which the work item belongs currently. Assigned To: The work item can be assigned to a team member, and the name of the current assignee will be recorded in this field. Discussion: The Discussion field allows multiple team members to discuss the work item by providing comments in the Discussion field. Each comment made in the Discussion field will be recorded with the date and time, and you are able to use rich text and images in the discussions to make them more useful. Priority: This is a subjective rating of the work items based on the relatedness to the business process. For example, you can set a value of 1 to denote that the priority is the highest; in other words, without the completion of this work item, the product is not shippable. A low value might indicate this work item can be considered as a “good to have” feature. Risk: This is the relative uncertainty on the completion of the story. Severity: This is the relative value considering the impact to the system. Story Points (Agile)/Effort (Scrum)/Size (CMMI): This is the relative size of the work item. In Agile, the relative size is measured with story points. Tags: Work items can be added with tags, which are discussed in detail in Lesson 4-5. Go to the user story backlog by selecting the “Backlog Work Item type” selection drop-down in the Backlogs view. Then you can use drag and drop or select “Move to position” in the context menu of the user stories to reorder them according to the business priority. Open the topmost user stories by clicking each one’s title, and fill out the story points. In Agile, you should get your team together and decide on the size of each user story. We will discuss this in Lesson 10-3 of this book. See Figure 3-20 for a sample backlog. Figure 3-20 Sample backlog In addition, clicking a work item will open the work item in any view such as work items, backlog view, or boards view. The work item form can be used to edit a given work item’s fields. There is a context menu in each work item to perform several actions for a given work item. We discussed the most commonly used work item fields in this lesson. Throughout this book series, we will further discuss these fields. Lesson 3-4. Selecting Work to Move to an Iteration Now that you have created a backlog in Lesson 3-2, we’ll show how you can move work to a time-bound iteration/sprint in this lesson. Prerequisites: You need to work through Lessons 3-2 and 3-3 of this chapter and have a backlog created. Open the backlog view for user stories. Then enable the side

Hands-on Azure Boards PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue