©  Ambily K K 2020
A. K KAzure DevOps for Web Developershttps://doi.org/10.1007/978-1-4842-6412-6_3

3. Requirements Management Using Azure DevOps

Ambily K K1  
(1)
Hyderabad, India
 

Requirements management is important for the success of any project. A proper requirements management tool will help you gather the requirements from various stakeholders and from various perspectives, with an end-to-end traceability to different components of the software development. Azure DevOps provides a set of features to handle the requirements and associated functions. This chapter will deep dive into the requirements management features provided by Azure DevOps.

Process templates define the way the project gets executed and the different requirement categories like task, user story and so on. We discussed various process templates in previous chapters. The rest of this book will focus on scrum-based process templates. Other templates aren’t that different except for the requirements handling.

Work Items

Work items capture the requirements in a systematic way. Based on the process template you have selected, different work items will be available for tracking the overall progress of the application development. When using the Scrum template, the following are the different work items available for tracking the requirements:
  • Epic: This captures the high-level business requirements. If the epic is complex, it can be further defined into child epics to track the requirements properly.

  • Feature: This defines the functional features being released as part of the application. Epics will be mapped to multiple features or product backlog items (PBIs) in a parent-child relationship, which will fulfil the expected business requirements.

  • Product Backlog Item: This will track the user-specific actions.

  • Task: This is the implementation work that needs to be accomplished to develop the product.

  • Bug: This tracks any functional or nonfunctional defects in the implementation.

  • Impediment: This tracks the challenges in executing the project.

  • Test Plan: This captures the overall test strategy followed by the team.

  • Test Suite: This is set of test cases is used for testing a specific feature, release, or module.

  • Test Case: This is set of steps, that will be executed to validate the correctness of the feature implementations.

The “Work items” section is where you define new work items and associated functions. Let’s explore the different features available in this section.

Work items

The New Work Item option is used to add new work items to the project. The Scrum process template allows you to capture the requirements using work item templates, as shown in Figure 3-1.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig1_HTML.jpg
Figure 3-1

New Work Item option

Create an epic to explore the different fields and options available as part of a work item, as shown in Figure 3-2.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig2_HTML.jpg
Figure 3-2

New epic

Work Item Fields: Details Tab

The Details tab captures all the relevant details associated with the work items such as the description, priority, and so on.
  • Title: This is a brief description of the requirement. For example, the description “Mobile Experience” means that the business expects the application to run properly on a mobile device.

  • Assigned To: Once the epic is ready to start working, it can be assigned to a team member to refine it.

Note

Backlog refinement, formerly known as backlog grooming , is the process of consolidating different viewpoints, boundary conditions, risks and mitigations, option validations, and overall aspects of the requirement. Different stakeholders discuss the requirements and capture all the aspects, which helps the implementation team to fulfil the requirement. Another important concept is backlog prioritization , where teams prioritize the product backlog items to sequence the development and deployment of features.

  • State: This defines the current progress of the work item. The State values for an epic are New, In Progress, Done, and Removed.

  • Area: This lists the area mapped to the team in Project Settings ➤ Team Configuration.

  • Iteration: Similarly, an iteration defines the iterations mapped for this team under Project Settings ➤ Team Configuration. If a project-level area or iteration is not visible to the team, then verify it under Project Settings ➤ Team Configuration.

  • Description: This field explains the requirement in detail, which provides enough details for the implementation team to meet the requirement.

  • Acceptance Criteria: This defines the verification condition, which verifies the completeness of the work item implementation. For the task level, the acceptance criteria can be the technical implementation of that task. From an epic level, this can describe how you verify the implementation of a business or architectural epic.

  • Discussion: This field provides an option to collaborate with other team members to discuss various details about the work item, as shown in Figure 3-3. You can ask questions related to the work item to specific people by adding the member name with an @ symbol, you can refer to another work item with the # work item ID, and you can provide feedback about the description or acceptance criteria of the work item.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig3_HTML.jpg
Figure 3-3

Discussion section

  • Status: Under Status, there are options to specify the start date and end date of implementing the specific epic. This data will help the implementation team to prioritize and calculate the overall effort for developing the epic.

  • Details: Under Details, data is captured for multiple fields.
    • Priority: This defines the priority of the epic.

    • Effort: This is the estimated effort for implementing the specified epic. This field helps the team to define the relative efforts for the features, product backlogs, and tasks derived from this epic.

    • Business Value: Here, you specify a priority that captures the relative value of an epic, feature, or backlog item compared to other items of the same type. The higher the number, the greater the business value. Use this field when you want to capture a priority separate from the changeable backlog stack ranking in Azure Boards.

    • Time Criticality: This is a subjective unit of measure that captures how the business value decreases over time. Higher values indicate that the epic or feature is inherently more time-critical than those items with lower values.

    • Value Area: This is the customer value addressed by the epic, feature, or backlog item. Values include the following:
      • Architectural: Technical services to implement business features that deliver a solution

      • Business (Default): Services that fulfill customers or stakeholder needs that directly deliver customer value to support the business

  • Deployment: This section relates to the release pipeline and shows which release contains the implementation of this epic. This will establish an end-to-end traceability for each of the business requirements. This field will be discussed further in Chapter 6.

  • Development: This section links the epic to the branch that holds the implementation, the build that contains the changes, or the commits that capture the implementation. Select the “Add link” option to link to an entity explaining the implementation of the epic. This process can be automated using the repo policies defined in the previous chapter.
    • Link Type: This shows the linked item type. This can be as follows:
      • Build related: This links to the build containing the implementation of the specific epic using the following options: Build, found in build, or Integrated in build.

      • Code related: This links to the implementation code using the following options: Branch, Changeset, commit, Pull Request, or Versioned Item. In large projects, epics may hold a completely new feature, and the development team may create a new branch to handle the feature development. In such a scenario, the epic will be linked to the corresponding branch to establish the end-to-end traceability. Commits and pull requests are used to link to Git-based version control, whereas Changeset and Versioned Item are used for TFVC.

      • GitHub: This is the new link type introduced to handle the GitHub integration with Azure DevOps. If your version control is based on GitHub, use this option to link the implementation with an epic. The options available are GitHub Commit and GitHub Pull Request.

    • The remaining fields change based on the Link Types selection. If this is set to Branch, then the options allow you to select a repository associated with the projects in the organization. Once the repository is selected, it displays all the branches related to that repository for selection. Provide a comment to complete the linking of an epic with the implementation code or build. If Link Type is set to Build, the system provides an option to select one of the build number. Similarly, all other selections will provide respective fields to link to it.

    • Related Work: Before proceeding to define a related work item, save the current epic. Once the epic is saved and an ID is generated, go to Related Work to define the related work items. There are two options to add an existing item or a new item. Existing Item provides an option to link an existing work item with a relation.

    Select New Item to explore more about the related work item.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig4_HTML.jpg
Figure 3-4

Adding a link

New Item provides the option to define the link type, as shown in Figure 3-4, (which is different from the previous link type) to handle the relationship with the epic. The available link types are as follows:
  • Child: This defines a parent-child relationship. In the case of an epic, it can be further defined into features, product backlogs, tasks, and so on.

  • Duplicate: This allows you to duplicate the same epic to handle another variation or to add to another project to implement similar feature.

  • Duplicate Of: This specifies that the current epic is a duplicate of another one defined in the same project or a different project.

  • Parent: A new item is going to be the parent of the current work item.

  • Predecessor: This establishes a sequential relationship to execute the dependent requirements in sequence. A new item should be created before implementing the current epic.

  • Related: Both the items are related, but they may not have any specific relationship like parent-child or sequential execution.

  • Successor: A new item will be the next item to be implemented.

  • Tested By: A new item implementation will be tested by the epic description or used for verification.

  • Tests: A new item consists of the test cases corresponding to the epic, as shown in Figure 3-5.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig5_HTML.jpg
Figure 3-5

Link types

Add a child item to proceed. Once you provide the title information and click OK, the system will open the new item in a dialog so you can fill in the required information. Fill in the required details and select Save & Close to navigate back to the epic.

Work Item Fields: History Tab

In a work item, the History tab captures all the changes over time, as shown in Figure 3-6. All the operations are tracked by Azure DevOps for audit purposes. This tab shows the changes done by whom and when. Also, it captures the change details such as adding a new child item.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig6_HTML.jpg
Figure 3-6

History

Work Item Fields: Links Tab

Navigate to the Links tab to view all the related items, as shown in Figure 3-7. The system provides an option to add new or existing work items from this tab as well.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig7_HTML.jpg
Figure 3-7

Links tab

Select the ellipsis icon (…) to view the options available. For each linked item, the system provides two options.
  • Edit comment: You can edit the comment entered as part of linking an item.

  • Remove link: You can remove the relation or link between two work items.

Work Item Fields: Attachments Tab

The Attachments tab provides an option to attach the related documents such as the architecture diagrams, wireframes prepared for UI design, technical design decisions, or any other artifacts related to the epic, as shown in Figure 3-8.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig8_HTML.jpg
Figure 3-8

Adding an attachment

Once it’s added, the Attachment tab provides different views.
  • Grid View: This lists the attachments in grid format.

    Click the ellipsis icon (…) to view the actions available for the added attachments.

    • Edit comment: This allows you to edit the comments entered as part of the attachment upload.

    • Preview attachment: This is a preview of the attachment based on its type. If it is an image, it will display a preview. But, if the attachment is a document, it will not show any preview.

    • Download attachment: This allows you to download the attachment.

    • Delete attachment: You can delete unwanted or wrongly attached documents.

  • Thumbnail View: This lists the attachments in card format. Hover your cursor over the top of the card to view the context menu icon (…) and click it to view the menu options.

Work Item Options

Now, look at the options available on top of the epic defined. You have a set of options available in the top-right corner, which includes the Save button.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig9_HTML.jpg
Figure 3-9

Work item options

Other options available are as follows:
  • Follow: This allows you to be notified of the changes made to a work item.

  • Settings: This includes notification settings at a work item level. If any of the work items are so important or really impacting your activities or have high business value, you can track them using these settings. The options available are as follows:
    • Not Subscribed (Default): This is not subscribed at the work item level. But, if the work item will be part of any of the project or organization notification settings, this will be displayed.

    • Subscribed: You can receive all notifications related to a specific work item.

    • Custom: This allows you to select specific notification options such as sending a notification only when there is a state change.

  • Refresh: Refresh the item to reflect the changes made by another user or in another system; for example, a commit linked to the work item will get reflected immediately.

  • Revert: Revert the unsaved changes. If there are no unsaved changes, then both the Save and Refresh icons are disabled.

  • Options (…): This provides additional actions and configurations for a work item. The options available are as follows:
    • New linked work item: This is another option to add a linked work item.

    • Change type: Change the type of a work item; for example, you can change an epic to a feature or change a task to the product backlog based on detailed analysis. The “Change work item type” wizard provides an option to select the target type and provide a reason for the change. This information will be tracked as part of the history of the work item and can be audited in the future to understand the reason for the change.

    • Move to team project: Move the existing work item to another project within the organization. Also, this option allows you to change the work item type as part of the movement, if required. The “Move work item” dialog provides an option to select the target project, type and provide the reason for the movement for tracking purposes.

    • Create copy of work item…: Create a copy of the existing work item in the same or different project. This option also allows you to copy the work item to a different work item type. At the time of the copy, the system allows you to include related artifacts such as the attachments, links, and child work items.

    • Email work item: Share the work item over email. This option opens the email construction page with options to add to email IDs, specify a subject, add details on a note field, and attach the main details of the work item. Work item data can link to the work item by adding a hyperlink to the work item ID. The receiver of the email can open the work item directly using this link.

    • Delete: Delete the current work item.

    • Templates: Create a template to define the default values for a set of fields. For example, you can define a task template with a predefined area path for a team and share it with them, as shown in Figure 3-10.
      ../images/501036_1_En_3_Chapter/501036_1_En_3_Fig10_HTML.jpg
      Figure 3-10

      Capturing a template

      Once it’s saved, use “Copy link” to copy the link of the template, which can be shared with others or posted on your team configuration or dashboard to create new work items based on this template. The template can be applied by selecting the work item context menu as well.

  • New branch: This option allows you to create a new branch out of the existing branch and link to the current work item. When the epic represents a feature and a feature branch strategy is followed by the team for the development of features, then this option supports the quick branching and linking operations.

  • Request Feedback: You can request a team member or stakeholder verify the completeness of the current work item or provide feedback on the work item. This feature is used to fine-tune the work items before considering them as part of sprint planning or can be used to get different viewpoints or sign-off from concerned stakeholders, as shown in Figure 3-11.
    ../images/501036_1_En_3_Chapter/501036_1_En_3_Fig11_HTML.jpg
    Figure 3-11

    Requesting feedback

    The “Request feedback” dialog allows you to specify the target members of the feedback request and instructions to provide the feedback, as shown in Figure 3-12. The Preview option shows the preview of the mail shared with the team.
    ../images/501036_1_En_3_Chapter/501036_1_En_3_Fig12_HTML.jpg
    Figure 3-12

    Preview feedback request 1

    Figure 3-12 shows the preview of the request feedback email. The email captures the project name and the team that the requestor belongs to. Scroll down to view the “Provide feedback” button. Clicking this button takes the user to the specified work item, where the user can provide the feedback in the Discussion section.

  • Customize: This will take the user to Organization Settings ➤ Boards ➤ process customization. Process template customization is covered in Chapter 2.

  • Keyboard shortcuts: This option highlights the important keyboard shortcuts used in Azure DevOps. By clicking the link “Full list of keyboard shortcuts,” you can refer to the complete set of shortcuts.

The remaining two options available on top of the work item are comments and Add tag.

  • Comments: This provides the number of discussions added to the work item and a navigation link to the Discussion section in the work item.

  • Add Tag: This option provides a facility to add tags to a work item. Tags help filter and query the work items.

Filters

Navigate back to the “Work items” section to view all the work items created so far, as shown in Figure 3-13.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig13_HTML.jpg
Figure 3-13

Work items

As you can observe in Figure 3-13, a set of filtering options is available just above the list of work items. These options help to filter the required work items. The filters available are as follows:
  • Filter By Keyword: Filter the list of work items by using keywords such as feature or epic based on the requirement.

  • Filter by Type: Filter the work items based on type. This filter option lists all the work item types available based on the process template. Multiple types can be selected to view the work items of various types.

  • Filter by Assigned to: Filter based on the assignment of work item to team members.

  • Filter by State: Filter based on the various states of the work item.

  • Filer by Area: Filter by the areas defined.

  • Filter by Tags: Filter by the tags. This option allows you to combine the tags using the OR and AND operators.

View Options

Figure 3-14 shows the view options available on the top-right side of the work items.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig14_HTML.jpg
Figure 3-14

View options

  • View: This will allow you to view completed work items in the list or not.

  • Filter: This option allow you to view filter options, discussed in the previous section.

  • Full Screen: The last icon allows you to view the work items list in full-screen mode.

Options

The following are the options available on top of the work item listing:
  • Recently Used: This drop-down provides options to filter based on a few parameters such as the work items assigned to the user, work items the user is following, and items where the user’s name is mentioned in discussions, related to his activities, and based on recent state updates.

  • New Work Item: This option supports the addition of new work items to the project and was discussed already earlier in the chapter.

  • Open in Queries: This opens the filtered work item list in the Query window, where you can add more filters and query elements. We’ll discuss queries in more detail later in this chapter.

  • Column Options: This option allows you to add new columns or remove an existing column from the grid view of the work items, as shown in Figure 3-15. Also, you can set the default sort order of work items based on specific columns.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig15_HTML.jpg
Figure 3-15

Columns

  • Import Work Items: Work items can be prepared offline using CSV files and imported into the system in bulk.

    Explore this feature further using the sample CSV file content shown in Figure 3-16, with one task and one bug. If required, we can add more columns such as Description, Area Path, etc., and capture the requirement details.
    ../images/501036_1_En_3_Chapter/501036_1_En_3_Fig16_HTML.jpg
    Figure 3-16

    Data

    Select the Import Work Items option to upload the file to Azure DevOps.

    The system will parse the data based on the columns defined and shown to the user to confirm, as shown in Figure 3-17. The user can either edit the data or save it as is.
    ../images/501036_1_En_3_Chapter/501036_1_En_3_Fig17_HTML.jpg
    Figure 3-17

    Uploaded data

    Select Save Items to create the work items and generate the IDs for newly created work items, as shown in Figure 3-18.
    ../images/501036_1_En_3_Chapter/501036_1_En_3_Fig18_HTML.jpg
    Figure 3-18

    Saving items

  • Recycle Bin: Azure DevOps allows you to remove the unwanted work items by changing the status to Remove. Once the work items are marked as Remove, they will be moved to the Recycle Bin, where the user can permanently delete the work item or restore it by changing the state.

Boards

Boards support another view of the work items and provide additional options to perform different activities related to the work items. By default, there will be one board configured for every team. The user can mark one of the boards as their favorite.

Select one of the boards to navigate to the specific board and view the work items, as shown in Figure 3-19. Each of the work items is displayed as a card with specific fields.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig19_HTML.jpg
Figure 3-19

Selected board

Board Selection

There are multiple options available to process the board and work items. Let’s start exploring the features from the top level. In the top-left corner, there are options to select a different board. Select another board from the drop-down list to navigate to a different board, based on your permissions, as shown in Figure 3-20.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig20_HTML.jpg
Figure 3-20

Team board selection

Use the star symbol on or near the team board selection to mark a specific board as your favorite. Select the people icon next to the star symbol to view the Team Profile page. This view lists the board, backlog, sprints, and dashboard corresponding to the team. Also, this view shows the members who belong to the team.

Analytics

The next set of options under the team board name consists of the following options:
  • Board: Work items will be displayed as cards in a board.

  • Analytics: This shows the analytics report in terms of cumulative flow diagram and velocity.

    The Cumulative Flow Diagram: Get insights about a selected team’s workload, throughput, and potential bottlenecks, as shown in Figure 3-21. ​To customize the report, set the columns, swimlanes, and timeframe. ​

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig21_HTML.jpg
Figure 3-21

The cumulative flow diagram

Velocity Report: This shows the team’s average speed in completing work across several sprints, as shown in Figure 3-22. Team velocity is a measure of how much work a team can complete during a sprint based on different metrics such as effort based on PBIs, story points based on user stories, and size based on requirements. Use this information to plan future sprint capacity.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig22_HTML.jpg
Figure 3-22

A velocity report

This report can be customized based on the effort, remaining work, business value, and count of work items along with the number of iterations to be considered.
  • View as Backlog: Display the work items in a backlog view, which will be discussed in the next section.

View Options

Similar to the “Work items” section, boards also provide different view options at the top-right corner, as shown in Figure 3-23.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig23_HTML.jpg
Figure 3-23

View options for boards

The first option allows you to view the board of backlog items, epics, and features. Based on the selection, the board changes the columns displayed and the work item types. Figure 3-24 shows the epics view of the board, where the columns have changed to New, In Progress, and Done.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig24_HTML.jpg
Figure 3-24

Epics view

The second icon (../images/501036_1_En_3_Chapter/501036_1_En_3_Figa_HTML.jpg) shows an option to toggle the live update on and off. The third icon (../images/501036_1_En_3_Chapter/501036_1_En_3_Figb_HTML.jpg) toggles the filter options on the top of the board. The last icon (../images/501036_1_En_3_Chapter/501036_1_En_3_Figc_HTML.jpg) allows the user to navigate to full-screen mode.

Board Settings

Clicking the gear symbol brings up the team configuration, especially the board-level configurations. The Settings dialog supports various options to customize the cards and board.

Cards Configuration

The settings in this section help customize the card data and its look and feel.
  • Fields: This section lists the fields displayed in the card. The user can configure the fields of importance here.

  • Styles: Define a style rule to make the important content stand out. In Figure 3-25, the selected style defines the bugs with a different background color; this makes the bug stand out in the board.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig25_HTML.jpg
Figure 3-25

Cards Style 1

Once this style applied, the board changes its display of bugs, as shown in Figure 3-26.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig26_HTML.jpg
Figure 3-26

Card style 2

  • Tag Colors: Tag colors support the configuration of different tag colors. Select a tag and configure the color against each tag to highlight some of the important tags in the board.

    Once the tag colors are applied, the cards will change the display of the tags, as shown in Figure 3-27.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig27_HTML.jpg
Figure 3-27

Tag color

  • Annotations: Annotations show the number of tasks, tests, or GitHub linked to the current work item, as shown in Figure 3-28. By default, all these visual icons are selected and shown on the card.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig28_HTML.jpg
Figure 3-28

Annotations 1

In Figure 3-29, there are three tasks associated with the current work item and one test case. Out of the three tasks, one is completed, and other two are in progress.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig29_HTML.jpg
Figure 3-29

Annotations 2

  • Tests: This configuration defines how the tests should be displayed on the card.

Board Configuration

The board configuration section defines the customization options available to configure the board. The following are the options available:
  • Columns: This defines the columns available in the board. By default, there are four different columns: New, Approved, Build and Test, and Deploy.

    Each column section shows the column name and status mapping for the bug and product backlog item. This setting is related to backlog items. If we open the settings related to an epic or feature, different options will be listed.

    The Approved column has additional options to configure the work in progress limit, indicating the number of work items that should be displayed or shown as in progress. This section allows you to split the column into doing and done as well. The definition of done is another configuration available to define the criteria for qualifying a work item marked as Done. The Build and Test columns have similar options to configure the WIP, definition of done, and splitting of the column.

    Moreover, this tab enables you to add a column to the board either using the plus sign on top or using the options on the header of the column names, as shown in Figure 3-30.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig30_HTML.jpg
Figure 3-30

Column movement

  • Swimlanes: Swimlanes allow you to group the work items horizontally. By default, there will be only one swimlane available. This setting allows you to add more swimlanes to group the work items horizontally on the board. In Figure 3-31, two new swimlanes are configured: Bugs and Product Backlog.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig31_HTML.jpg
Figure 3-31

Swimlane 1

By default, newly created swimlanes will be blank. The user can drag and drop the work items to arrange the same horizontally using different swimlanes, as shown in Figure 3-32.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig32_HTML.jpg
Figure 3-32

Swimlane 2

  • Card reordering: This configuration defines the behavior of a card when dragging and dropping to a new column. There are two options available to order the card: either to place the new card in the drop location or to push it to the beginning and keep the order of the other cards as is, as shown in Figure 3-33.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig33_HTML.jpg
Figure 3-33

Card reordering

  • Status Badge: Badges will be used to display the current status of the team on the dashboard. Badges can be configured using this section and copying the image URL, which can be inserted into any custom application to display the status information, as shown in Figure 3-34.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig34_HTML.jpg
Figure 3-34

Status badge

General Configuration

This section contains the general settings related to the team board:
  • Backlogs: The backlog configuration allows you to configure the backlog navigation levels available in the team board.

  • Working days: This configuration allows you to configure the working days of the team. This information supports the capacity planning of the team.

  • Working with bugs: This configures how the bugs will be handled by your team. Some teams consider bugs along with tasks and include them in sprint planning; others treat bugs differently and will not include them in the backlog and sprint planning area.

Cards

Each card in the board represents one work item. If the view selected is for backlog items, then the card shows backlog items associated with the current team. At the beginning of the card, there is an option to add a new item using this icon: ../images/501036_1_En_3_Chapter/501036_1_En_3_Figd_HTML.jpg. This option supports the creation of a new product backlog or bug. If the view changes, then this option allows you to create a new feature and epic.

Every card has the feature to drag and drop across the board, which will change the status of the item based on the drop location or column. Cards will have a badge indicating the type of work item and the title, as shown in Figure 3-35. The remaining fields are optional and can be configured based on the card settings.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig35_HTML.jpg
Figure 3-35

Card

The card settings provide the option to inline edit the content such as the assignment, effort, priority, state, and area path. When selected, each of these fields provides the list of valid values and allows a change in value, as shown in Figure 3-36.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig36_HTML.jpg
Figure 3-36

State

Each card has a top-right corner menu (…) to support additional operations, as shown in Figure 3-37.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig37_HTML.jpg
Figure 3-37

Context menu

The following are the additional options available in the Card menu:
  • Open: This allows you to open the work item as a pop-up. A work item can be opened by clicking the title of the work item as well.

  • Edit Title: This allows inline editing of the title.

  • Move to iteration: Assign the work item to a specific iteration such as Sprint 2 or Sprint 3.

  • Add Task: Add a subtask to implement the product backlog item fully or partially. One product backlog can have multiple tasks to implement it. The Add Task operation expands the card and provides an option to enter the title of the task.

    Once it’s added, the user can navigate to the task by clicking the title and filling in the remaining details, if required.

    Also, this view allows you to drag to rearrange the order of the tasks. Newly added tasks can be moved up to complete them first or to set a higher priority for them.

Note

If the user selects the task using the check box, this indicates that the task is completed and marked as done.

  • Add Test: This is the same as adding tasks. The user can add test cases against a product backlog item to test the functionality.

    A test suite corresponding to the test cases can be opened using the right arrow next to “Add test.” Figure 3-38 shows the test suite opened for some test cases. We’ll discuss test suites in more detail later in the chapter.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig38_HTML.jpg
Figure 3-38

Test suite

  • Delete: Delete the work item. This will move the work item into the Recycle Bin. The user can restore the work item, if required.

  • New Branch: Create a new branch to implement the current work item and link to the work item.

Backlogs

The Backlogs section provides another view of work items and supports most of the options available in boards, as shown in Figure 3-39.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig39_HTML.jpg
Figure 3-39

Backlog Tab

Instead of listing the work items as cards, they are displayed as a grouped list along with option to do iteration or sprint planning. Options such as the team backlog filter; favorite icon; team settings; filters; different views based on backlog, epics, and feature; filter options; analytics; and new work items are the same as boards. Additional options will be discussed in this section.

Backlog items can expand to view the tasks defined under each backlog. Use the + and – icons available on the header of the backlog list to expand and collapse all the items at once. For planning the activities for each of the sprints, backlog items can be dragged and dropped into the corresponding sprint displayed on the right, as shown in Figure 3-40.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig40_HTML.jpg
Figure 3-40

Backlog planning

Using the New Sprint option at the end of the Planning blade, you can add more iterations/sprints to the list. The Planning blade can be closed to view more fields of the work items.

Column Options

This option helps in configuring the columns required in the list of work items. There are two types of columns. One is related to the fields associated with the work item, and another is related to a rollup column. The rollup column is a calculated field based on the subtasks and linked items. In the case of a product backlog item, rollup columns consider the tasks and test cases linked to the backlog item.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig41_HTML.jpg
Figure 3-41

Column options

In Figure 3-41, there are two rollup columns configured: Progress by Task and Count of Task. Figure 3-42 shows the new view of the backlog.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig42_HTML.jpg
Figure 3-42

Rollup columns

Rollup fields provide a lot of information about the completeness of the task and the related work items.

The predefined rollup fields are as follows:
  • Progress by all Work Items: Progress indicator by calculating the progress across all work items associated with the current backlog item

  • Progress by Bug: Progress calculation only based on bug

  • Progress by Effort: Progress based on effort

  • Progress by Task: Progress by tasks completion

  • Count of Work items: Count of associated work items

  • Count of Bug: Count of bugs logged against the backlog

  • Count of Task: Count of task

  • Sum of Effort: Sum of the efforts

  • Sum of Remaining Work: Sum of remaining work

In addition to these predefined rollup columns, Azure DevOps provides an option to define a custom rollup, as shown in Figure 3-43.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig43_HTML.jpg
Figure 3-43

Custom rollup 1

Select “Configure custom rollup” to proceed. Select the rollup type from the options; you can select a progress bar or a total display, as shown in Figure 3-44. Also, select the work item type and column metrics (Count or Sum).
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig44_HTML.jpg
Figure 3-44

Custom rollup 2

Options

Multiple options are available in a backlog to handle the work items and maintain them. The More Commands (…) option next to the Columns provides the options Create Query and Email, as shown in Figure 3-45.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig45_HTML.jpg
Figure 3-45

Backlog options

Create Query captures the filtered work items as a query for future usage. We’ll discuss queries in more detail later in this chapter. The Email option will be used to share the listed work items over an email format.

The basic work item details along with a link to the work item will be captured in the email.

Another set of options is available for the work items listed in the view. Select the icon (…) next to the title of the work item to invoke other operations available, as shown in Figure 3-46.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig46_HTML.jpg
Figure 3-46

Backlog options

Most of these options were discussed in detail in previous sections. Backlog view supports bulk editing as well as applying an action to a set of work items at once.
  • Edit: This allows you to edit the fields of the work item. The user can select multiple work items by using Shift and the arrow keys. After selecting multiple items, select the Edit option to edit a set of fields at once, as shown in Figure 3-47.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig47_HTML.jpg
Figure 3-47

Editing a work item

In Figure 3-47, 12 items are selected with the area path set to SampleDemoProjMobile and different efforts. Change the area path and effort in the edit dialog and click Save. As shown in Figure 3-48, the effort and area path of the first 12 work items changed.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig48_HTML.jpg
Figure 3-48

Bulk edit result

  • Assign to: Just like the Edit option, this option supports the bulk assignment of selected work items.

  • Copy to clipboard: This selects a set of work items and copies the listed field details into a file.

  • Delete: This deletes the selected work items.

  • Templates: This captures the template out of a work item, as explained in the previous section.

  • Add link: This adds a link to an existing or new work item. This operation supports the linking of multiple work items with a single work item. But the linking may fail based on the relationship or link type selected for the work item link. For example, in Figure 3-49 there are 12 work items selected and trying to link to an existing work item with the link type as Child.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig49_HTML.jpg
Figure 3-49

Adding a link

As the link type is Child, only one work item will be able to link with the selected work item. The remaining links will fail, as shown in Figure 3-50.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig50_HTML.jpg
Figure 3-50

Adding a link result

  • Move to iteration: This maps the selected work items to an iteration or sprint.

  • Change parent: This changes the parent of the work item to a different existing work item.

  • Move to position: This option helps in reprioritizing the work items in the Backlog view. This can be done by dragging the work items to different positions as well.

  • Change type: This changes the type of the work item, as explained in the previous section.

  • Move to team project: This moves the work item to another team project.

  • Email: This emails the work item to a group or stakeholder to review the content.

  • New Branch: This creates a new branch for implementing this work item.

Sprints

The Sprints section provides a view of the work items planned for an iteration or sprint, duration of the sprint, progress of work completion, team working on the sprint, and other sprint-related information, as shown in Figure 3-51. Using boards and backlogs, the teams decides on the work items for a sprint. Once the work items are finalized for a sprint, the team can start implementing them based on the details available and not entertain any change in plan.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig51_HTML.jpg
Figure 3-51

Sprints

The sprint view provides various options for executing the sprint activities. This view will be used as part of daily standup meetings to track the progress. The top-left corner has options that allow navigation to the sprint directory and other teams’ sprint views, as shown in Figure 3-52. The next two icons show the favorite and team profile, the same as the Boards and Backlogs sections.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig52_HTML.jpg
Figure 3-52

Sprints options

The top-right corner shows the sprint start and end dates along with the burndown trend, as shown in Figure 3-53. Sprint start and end dates can be edited, but this is not recommended generally. Changes to sprint cadence or work items are not recommended after a sprint starts.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig53_HTML.jpg
Figure 3-53

Sprints: Top options

The burndown trend shows the progress of the sprint activities. Over time, the activities should be completed, and the trend line should go down. If the trend line does not show a steady decline, then there will be a chance of not completing the activities on time. We’ll discuss different sprint dashboards later in this book. By selecting the Burndown Trend icon, it opens up the Burndown Trend report, as shown in Figure 3-54.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig54_HTML.jpg
Figure 3-54

Burndown Trend report 1

You can drill down into this report further, and other details are available on the Analytics tab or by selecting the “View the full report” link at the top of this report, as shown in Figure 3-55.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig55_HTML.jpg
Figure 3-55

Burndown Trend report 2

The line shows the ideal trend, whereas the column shows the actual progress. Various filtering and search options are available on top of the report to extract the required information from this report.

Figure 3-56 shows the next set of options available just below the team name.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig56_HTML.jpg
Figure 3-56

More sprint options

  • Taskboard: This shows the sprint work items in the board, just like the Boards section. Work item cards provide similar options like the cards in the Boards section, which allows you to change the look and feel of the card and do limited operation on the work items.

  • Backlog: This is a similar view as the Backlog section, but limited with work items mapped for the selected sprint.

  • Capacity: This section helps in configuring the team capacity. Based on team availability, the total effort available for a sprint will be calculated. The team can enter the day off and partial availability data, which helps the sprint planning.

    Team can enter the day off using the link provided in the Capacity tab.

    Team can also specify the kind of work or activity one can perform, as shown in Figure 3-57.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig57_HTML.jpg
Figure 3-57

Capacity

Moreover, this tab helps in adding multiple activities for one team member and distributes that user’s availability or effort across multiple activities, as shown in Figure 3-58. The scrum master can use all these details to plan the sprint.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig58_HTML.jpg
Figure 3-58

Sprints: Capacity 2

  • Analytics: This shows the Burndown Trend report discussed in previous section.

  • New Work Item: This shows another option to add new work items to the list.

  • Column Options: This shows the different column options for the board. The user can add or remove columns based on the sprint requirements using this option.

  • Sprint: Select different sprints to view the work items planned for each sprint or the items completed in previous sprints.

  • Person All: You can filter the view with the assigned team member, as shown in Figure 3-59. This view will expand and shows only the work items assigned to the selected team member; the remaining work items will be in collapsed mode.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig59_HTML.jpg
Figure 3-59

Person view

  • View Options: By default, the taskboard displays work items grouped under backlog items. You can change this view to group them under the assigned team member using the People option. This will be helpful in driving the daily standup call and tracking the progress of individuals.

    Also, the user can select the side pane to display work details or planning. “Work details” shows the workgroup by activity and team member and shows the pending work or effort required to complete the work, as shown in Figure 3-60.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig60_HTML.jpg
Figure 3-60

Work details

Planning displays the iteration or sprints with a number of work items planned, planned efforts, start and end dates, and other details, as shown in Figure 3-61.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig61_HTML.jpg
Figure 3-61

Sprints: Planning

  • Filter: This toggles the filter options available for the board.

  • Settings: This is a subset of settings in the Boards section to decide on the card data and general settings.

  • Full Screen: This displays the section in full-screen mode, which provides additional screen space for users to work on the work items.

Queries

The Queries section supports the filtering of required work items based on various criteria. The initial view lists the saved queries under My Queries and Shared Queries, where My Queries will be available to only the user, and the Shared Queries will be shared across the team.

For better management, the user can create subfolders under My Queries and Shared Queries and move the appropriate queries into those folders. Use the option New folder on the top of the query list to create a new folder under any of the existing folders. The user can either define new queries or drag an existing query to the folder. In Figure 3-62, two existing queries were dragged to the new folder called Bug Related under Shared Queries.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig62_HTML.jpg
Figure 3-62

Folders

Import Work Items provides the option to import the CSV file, explained in the previous section. Filtering by keywords allows you to filter the query based on specific filter conditions such as a bug, as shown in Figure 3-63.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig63_HTML.jpg
Figure 3-63

Filtering queries

For each of the queries, there is an option to add the query to a favorite list by selecting the star icon. Moreover, there are multiple options available as a context menu for the folders and queries.
  • Run Query: This runs the query and shows the results page, as shown in Figure 3-64.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig64_HTML.jpg
Figure 3-64

Running a query

  • Edit: This allows you to edit an existing query.

  • Rename: This allows you to rename an existing query.

  • Delete: This deletes the query.

  • Add to Team Favorites: This allows you to add the query to a team’s favorite list.

  • Security: This defines the security and permission for the queries. Select the user or group and allow permissions such as Contribute, Delete, Permission management, and Read. The user can set permissions such as Allow, Deny, and Not set.

  • Add to dashboard: Add the query result in different forms to the team’s dashboard.

New Query

New Query will open the page with a default query condition, as shown in Figure 3-65, which lists all the work items with all states. Select the Run Query option to execute the default query, which displays the query result below the query itself.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig65_HTML.jpg
Figure 3-65

Default query conditions

By default, only a few columns are listed in the query result view. The user can add more columns using the Column options. The “Save query” option will be used to save the query into different folders.

Once the query is saved, new options to save the query with a different name (Save as) and Rename will appear on the top option list. The following are some of the other options available on top of the query editor:

  • The Results tab: This shows the query result on a separate tab.

  • The New option: This helps create new queries or work items.

  • Revert Changes: This will be enabled to revert changes that are not yet saved.

  • Email query: Email the current query result.

  • Copy query URL: This copies the current query URL, which will allow the team members to share it to other stakeholders to refer to a specific list of queries.

  • Export to CSV: This exports the result into CSV format for offline reference. After updates, this can be imported back to the system as well.

Type of Queries

There are three types of queries available.
  • Flat list of work items (Default): This is a list of work items, as shown in Figure 3-66.

  • Work items and direct links: These are work items with one level of child elements.

  • Tree of work items: These are work items with a multilevel view.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fig66_HTML.jpg
Figure 3-66

Flat list of work items

The “Work items and direct links” item shows the work items with direct links based on the filter options selected and the type of links selection, as shown in Figure 3-67.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig67_HTML.jpg
Figure 3-67

Work items and direct links

Different filter options are available, as shown in Figure 3-68.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig68_HTML.jpg
Figure 3-68

Filter options

“Tree of work items” is also controlled by different filter options and types of trees. There are two filter options available: Match top-level work items first and Match linked work items first. There are two values for the type of tree as well: Duplicate Of/Duplicate and Parent/Child, as shown in Figure 3-69.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig69_HTML.jpg
Figure 3-69

Tree of work items

Moreover, in both cases, there are filters corresponding to top-level work items and linked work items. Filters define the filter conditions or the requirements of the work items. New filters can be added using the plus sign available at the beginning of the filter row and deleted using the cross icon next to it. The third icon, the check box, represents the grouping of the filters based on a logical operation like AND or OR.

For example, Figure 3-70 shows the filer to view only the tasks and product backlogs with any state. Select the filters using the check box and click the group icon on top to group them.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig70_HTML.jpg
Figure 3-70

Filters

The next three columns show the field, operator, and value combination to define the core filter condition.

The user can query across all projects in the organization to view the work status across the organization. Select the “Query across projects” option to query the work items across the organization.

../images/501036_1_En_3_Chapter/501036_1_En_3_Fige_HTML.jpg

Work Offline

The Export to CSV option allows you to download the result of the query into CSV format.

The downloaded data will have the columns selected as part of the query result only. If you need more columns, select the column before downloading to include it in the result. If the result contains multiple Title fields, like the one shown in Figure 3-70, then the query will be either work items with a direct link or a tree of work items. In Figure 3-70, Title 1 shows the product backlog item’s title, whereas Title 2 shows the title of the task, the child of product backlog item.

To add or delete the work items offline to Azure DevOps, install and configure the Azure DevOps Office Integration from https://visualstudio.microsoft.com/downloads/.

Now, open an Excel file and navigate to the Team ➤ New List option.

Add or select the DevOps server to continue. Once the server is selected, all the organizations and team projects are listed, as shown in Figure 3-71.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig71_HTML.jpg
Figure 3-71

Connecting to the Azure DevOps server

Select the team project, connect to the project, and get the list of queries available, as shown in Figure 3-72.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig72_HTML.jpg
Figure 3-72

Selecting a query

Select the query and proceed to load the query result into the Excel sheet, as shown in Figure 3-73.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig73_HTML.jpg
Figure 3-73

Offline view of work items

Add new work items without an ID field or edit existing work item details to work offline on the work items, as shown in Figure 3-74. Once the edits complete, click Publish to publish the changes to Azure DevOps.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig74_HTML.jpg
Figure 3-74

Offline editing of work items

Once published, newly added IDs will be populated in the Excel spreadsheet, as shown in Figure 3-75. Excel provides a few additional options to manage the work items such as the ability to select columns, edit areas and iterations, and so on.
../images/501036_1_En_3_Chapter/501036_1_En_3_Fig75_HTML.jpg
Figure 3-75

Publishing work items

Summary

The Azure DevOps features support the end-to-end management of requirements from all aspects. Business requirements can be captured using various epics and features, whereas the low-level implementation tasks will be captured using product backlog items and tasks. The requirements are not limited to functional and architectural requirements; Azure DevOps also covers the NFRs such as scalability testing, security testing, performance testing, and so on. The system supports the traceability of the requirements in different dimensions such as the code developed based on the requirement, test cases that are executed to verify the requirements, defects identified in the implementation, the build or release containing the requirements, and so on.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.171.202