The Work Item Form

The work items are defined in the project template in Azure DevOps. The template and the work item types are defined in a set of XML files stored on the Azure DevOps server. The XML files for your work items define the information the work item includes on its form in Azure DevOps (Figure 4-4).

As you can see in Figure 4-4, the Bug work item type in Microsoft Scrum includes fields for many aspects of the bug. You can assign the bug to a specific person, set state (status), set severity, and much more. You can also add a description of the problem and attach files such as screenshots of the bug. There are other options as well, but they are not covered in this book.

The fields on the work item form can have properties set for them. You can let a field be read-only, required, automatically populated, and so on. Because you can also change the information included on this form by editing the XML, you can make sure it contains the information you want.

We have heard some customers say they have had problems using the process templates that Microsoft provides because the information required to fill in the forms is not the information they want to track or record. Instead of changing the work item types, they have tried to adapt to the work items. Don’t make this mistake! If you need other information besides what is included in the templates, or if you need the information in another way, change the template. That’s the whole point of having an open and flexible solution such as Azure DevOps. You can adjust the tool to fit your needs. I have, for instance, seen the Bug work item that Microsoft uses, and it looks nothing like what is included in any of the templates you get with Azure DevOps. Instead, Microsoft encourages you to adjust the tool to your needs. This includes adjusting the work items.

Work Item Traceability

You enter this user story into Azure DevOps and Azure DevOps assigns an ID to it (Figure 4-5). This ID follows the work item throughout its life.

In Figure 4-6, you can see that you can associate the work item with test cases, tasks, and other work items. This means you get traceability from a requirement to test cases, to storyboards, and to other work items.

You can also do this the other way around. When creating bug work items, test cases, or work items, you can link them to a new work item (Figure 4-7) or to another, existing, work item. This is a huge benefit over keeping this information in our head or on an Excel spreadsheet.

You can also define check-in rules for your developers, which forces them to associate a check-in/“changeset” with a work item (Figure 4-8). There shouldn’t be a need for a check-in unless the code change is associated with a work item. You should never do any code changes unless they are required to solve an issue, and this issue should always be documented as a work item.

By associating a build with a changeset, you create traceability from the original requirement (user story, in this case) to the built executable. This traceability can help you avoid problems such as the ones described at the beginning of this chapter.

By using the reporting functionality of Azure DevOps, you can see quickly what a work item is associated with and hence know that if you change some part of the code (like with a bug fix), this change affects a specific work item. Knowing this, you can see that some test cases will be affected by the change and that you need to run those tests again to determine whether the change broke anything. You can also get warnings from Azure DevOps that a check-in affects certain test cases.

Figure 4-9 shows what traceability can look like. When you examine this figure, you should be able to understand easily the importance of traceability and the help you have from good traceability implementation. You can also see that this way of working leaves you in a much better spot if you, somewhere down the road of a production system, need to implement changes. You can then follow the trace to determine which parts of the code are affected by a change and which test cases might need to be changed.

Work Item Queries

Using Team Explorer, you can query work item databases (Figure 4-10) by using WIQL, which has a SQL-like construct. From Team Explorer or Azure DevOps, you can create new queries or modify existing ones.

Depending on the process template you use, the work item queries supplied differ quite a bit. Microsoft Scrum has different work item queries than the Agile template, for instance. When we used the Agile template in some of my projects, we have found it necessary to add new work item types because the organization needed them for their ALM process. Queries to get information about these new work item types naturally don’t exist, so we had to make these queries ourselves. Some of these queries were built during the projects when the need arose, and many of them were later included in the process template so they are now part of all new projects.

Conclusions on the Work Item Tracking System

The work item tracking system is one of the core components of Azure DevOps. This system allows you to create work items and enable traceability. You can use the work items included with Azure DevOps from the beginning, you can adjust them to your needs, or you can even create your own work item types. Each work item has a unique ID (as you saw earlier in Figure 4-1) that you can attach to the things you do in Azure DevOps. This enables you to follow one work item—let’s say a requirement, for example—from its creation to its implementation as a piece of executable software. You can also associate one work item with others and build a hierarchy of work items.

When a bug is discovered, you can quickly follow the original requirement by its work item ID and see in which places of the code you might have to make some fixes. You can also see the associated work items, so you can evaluate whether other parts of the code need to be changed as a result of this bug fix.

If you implement a requirement as a work item, you can use the work item ID to track the requirement through source code to the final build of the executable system. By requiring all developers to add one or more work item IDs to the check-in using a check-in policy, you enable this traceability.

Our suggestion is that you look closely at the work item types supplied by Microsoft. Then you can decide which of these you can use for yourself and which you might adjust to suit your organization’s needs. If none of the ones supplied can be used, you can create your own work item types. Use this opportunity! Don’t adjust your way of working to the Microsoft templates. Adjust Azure DevOps to your needs instead.

Scrum

The Scrum process is built on the Scrum framework. Microsoft worked with Scrum.​org when it developed the Scrum process for Azure DevOps/VSTS, and this is evident when you look at the terminology used in the process.

In Figure 4-11, you can see that there are work items that work on three different levels. The Scrum process lets you manage work items at the portfolio level as well as the backlog level (work in sprints). There are Epics and Feature work items that help you handle the portfolio backlog level. You can use Azure DevOps/VSTS to implement a program team that manages the overall high-level requirements using these two work item types. For the daily work in sprints, one or more teams can have a subset of the portfolio backlog dedicated to that specific team whereas other teams have their own subsets independent of the other teams. In Chapter 6, we see how we can use the features of Azure DevOps to set up such a scenario.

Development teams usually work with work items on the backlog level. There you find PBIs and their associated tasks. You can configure bugs and their tasks to be part of this level (Figure 4-12). These work items are followed up only on remaining work, similar to the Agile world.

How you work with bugs is configurable (Figure 4-13). You can allow bugs to be seen on the boards and backlogs on the same level as requirements or tasks. Or, you can choose not to have bugs appear on the boards and backlogs at all. You can change the desired behavior when you want so you are not locked in to the first choice you make.

Agile

The Agile process has been developed in collaboration with the Agile alliance. Originally, it was called the Microsoft Solutions Framework (MSF) for Agile, but now it is only referred to as the Agile process in Azure DevOps/VSTS.

This process is aimed at supporting Agile teams, even those that use Scrum as their process. It tracks development and test activities separately, just like the Scrum process. It also has three levels of work items, as shown in the previous section (Figure 4-14).

If you compare Figures 4-11 and 4-14, you see they are very similar. Only the names are different. For instance, Impediment in Scrum tracking is called Issue in the Agile process, requirements are called User Story in the Agile process and Product Backlog Items in the Scrum process. The difference between the two is more evident if you look at how the requirements are documented (Figures 4-15 and 4-16).

Comparing these two figures, you can see similarities, such as the description and acceptance criteria. But, if you look at the details, you find things that differ. The field for estimating a requirement is called Effort in the Scrum process and Story points in the Agile process.

Another difference is in how you track your progress. In the Agile process, tasks support tracking Original Estimate, Remaining Work, and Completed Work; in the Scrum process, only Remaining Work is tracked. In my view, only the remaining work is important, but I do realize some organizations have a demand for tracking more than this.

Take some time and study the different work item forms in your own environment so that you choose which is best for your organization. Keep in mind that you can always customize the process if you want (see Chapter 5).

CMMI

The last process we discuss is called CMMI . CMMI is a more formal project methodology we can use.

The work item types in CMMI are also on three levels, like Scrum and Agile (Figure 4-17). In CMMI, process requirements are called Requirements, not User Story or PBI.

Furthermore, you can see that you have more work item types for tracking your projects: Change Request, Issue, Review, and Risk. Using this process you can implement a formal change management process, such as the one found find ITIL .

ITIL, formerly an acronym for Information Technology Infrastructure Library, is a set of practices for IT Service Management (ITSM) that focuses on aligning IT services with the needs of business. In its current form (known as ITIL 2011 edition), ITIL is published as a series of five core volumes, each of which covers a different ITSM life cycle stage. International Organization for Standardization (ISO) develops and publish many international standards. Although ITIL underpins ISO/IEC 20000 (previously BS15000), the International Service Management Standard for IT service management, there are some differences between the ISO 20000 standard and the ITIL framework. ITIL will be updated to version 4 in early 2019.

ITIL describes processes, procedures, tasks, and checklists that are not organization specific, but can be applied by an organization to establish integration with the organization’s strategy, to deliver value, and to maintain a minimum level of competency. ITIL allows an organization to establish a baseline from which it can plan, implement, and measure. ITIL is used to demonstrate compliance and to measure improvement.

Figure 4-18 shows differences between how requirements are documented in CMMI compared to the two other requirements types discussed. You can see quickly that more details can be filled out by default. And like the Agile process, CMMI also supports tracking original estimates, remaining work, and completed work at the task level.

There are other work item types in these processes that are the same for all processes. We take a look at them shortly, but first a few words on workflow states.

Workflow States

Workflow states support tracking the status of work as it moves from a New state to a Closed or Done state. In Azure DevOps/VSTS, a workflow consists of a set of states, the valid transitions between the states, and the reasons for transitioning the work item to the selected state (Figure 4-19).

Work items are maintained in a team project as long as the team project is active. Even if you set them to Closed, Done, or Removed, a record is kept in the data store, which means you can use this data to create queries or reports.

If you need to delete a work item permanently, you can use the witadmin destroywi command-line tool. This tool is not discussed in this book.

Most work items that appear on backlogs and boards support any-to-any transitions. This means you can update the status of a work item using a Kanban board or a task board by dragging it to its corresponding state column.

You can also change the workflow so that you can have the states, transitions, and reasons you need in your team or organization. (More on this in the Chapter 5).

Work Item Types for All Processes

Let’s now take a brief look at them.

Work Items That Support MTM

Our testers and test managers often work with these work item types. The goal of this book is not to discuss testing in general, but we will provide a brief example here. Many test efforts are structured like this:

A test plan is created for a sprint using MTM or Azure DevOps. The test plan contains the high-level view of the testing effort. There is a Test Plan work item type included in all processes.

One or more Test Suites (another work item type) are created and included in the test plan. The suites themselves includes one or more Test Cases (work item type). The test cases are used to describe, step by step, how a tester should test the application or functionality being developed. Test cases are often associated with a requirement so that you can see which tests cover a specific requirement.

So, using test plans, test suites, and test cases, you can structure your testing efforts in a way that gives both traceability as well as visibility of your tests (Figure 4-20). You can generate reports and graphs that show the status of these work item types.

There are two more work item types for test, as shown in Figure 4-20:

1. 1.

   Shared Steps: This work item type includes test steps that can be reused in many test cases. They help in removing redundant test steps by allowing you to reuse them.

    
2. 2.

   Shared Parameters : When you write a manual test, you often want to specify that the test should be repeated several times with different test data. For example, if your users can add different quantities of a product to a shopping cart, you might want to check that a quantity of 200 works just as well as a quantity of one. To do this, you insert parameters in your test steps. Along with the test steps, you provide a table of parameter values. These parameters can be used to create shared parameters, which can be reused in other test cases.

    

When you develop an application, you usually want stakeholders or end users to provide feedback on what you have done. Using the feedback functionality of Azure DevOps/VSTS, you can ask reviewers to provide videos, screenshots, type-written comments, and ratings. Their feedback is captured into work items that you can review and use to create a bug or suggest a new backlog item. The two work item types are called Feedback Request and Feedback Response.

The last two work item types we discuss are aimed at code reviews. Code reviews are a critical part of software development. They help you keep your defect count down, as well as give you the opportunity to learn from other people’s code. A third benefit is that code reviews also allow teams to communicate to their peers changes to the application.

In Azure DevOps, there are two work items types that help with code reviews:

1. 1.

   Code Review Request: This type is a request a developer creates and sends to a peer to ask for a review of some part of the code.

    
2. 2.

   Code Review Response: A response gets created when the code review request goes out. The reviewer can choose to accept or reject the review.