Work Item Types

You can use the work item types that Microsoft ships with Azure DevOps in the three templates. But, as mentioned earlier, we think you should really consider your own needs in the organization and make adjustments to the templates based on them. Your organization might need more work items or might need to extend the information required for them. If your PMs use Microsoft Office Project, you might want to change the mapping between fields in TFS against fields in Project. Another thing to consider is the workflow of the work items. How is the process in your organization? Between which states can a bug transition? Microsoft supplies a set of default work item instances when a project is created that represent tasks that need to be done in all projects. Your organization might have different needs for default work items.

Work Item Queries

What information do you need to query about your work items? If you have made many changes to the work items, you might also need to change the queries so they reflect these changes. What queries does your DevOps process need? In Figure 5-4, you can see the queries of the MSF for Agile template.

Reports

Most of our customers modify their reports. The reports in the processes are very good. Figure 5-5 shows one of them that represents how much work is left in a project. When choosing which reports and information you need, we once again come back to the fact that this is something you need to discuss with your project teams and with stakeholders and managers. What information is important to the various roles in your ALM process? What do the managers need to see? How can you provide great feedback on project status to the team?

Areas and Iterations

Areas and iterations are interesting concepts. Iterations are what the term sounds like, basically. You use iterations to name the different versions of your project. You can name them anything you want. We have most often used the names Iteration 1, 2, 3, and so on, but how you name them is up to you. You can nest them and build an iteration hierarchy if you want.

Areas are labels you can attach to just about anything. One customer uses labels named after their Windows or web forms in their projects. Another uses them for each component in their system. Then they can use areas and iterations to describe which areas (forms) belong to a certain iteration.

What we want to say about this is that you can use areas and iterations to label specific parts of your projects. These concepts are flexible, and you have the freedom to use them as you want. All work items can be labeled later with both an area and an iteration. Depending on your DevOps process, you might use this for various reasons. If you run a project using SAFe, you might want to use the iterations by naming them after the ARTs, then you can nest iterations below each train depending on your need. Figure 5-6 shows an example of what this could look like. And if, during the project, you need more iterations in one phase, you can simply add them.

You can decide what you want to use labels and areas for. In our opinion, they are very useful. They give you enormous freedom in how you set up your projects, so I suggest you make good use of them.

Modifying Work Items

Microsoft encourages modification of process templates. We’ve found that work items are worth modifying. Many organizations have needed information in their work items that is not available in the three Microsoft templates. In these cases, we adjusted the work items to fit the organization better. This strategy has turned out to be very successful in all cases. One thing we changed was the workflow of the work items.

How to Open the Process Template

You can start creating an entire new process template if you want, but it is far easier to start by modifying an existing one. First you need to download the process template from the TFS server. In Team Explorer, go to Settings (Figure 5-7) and choose Process Template Manager, which is below Team Project Collection.

Select a process template for download and click Export from the Process tab in the web user interface the Process Template Manager opens (Figure 5-8). Select a location to download the process template. Close the Process Template Manager when you are done.

To modify the process template you just downloaded, go to the Tools menu in Visual Studio and start the Process Editor (Figure 5-9). You are provided with several options for what you can edit. As you can see in Figure 5-9, you can chose to edit the downloaded process template files or select an item from the server. With the latter option, you can edit the current installed process template, changing all future projects created using that template.

After you finished editing the downloaded process template, you can rename it and upload it to the server as a new process template available for all new team projects.

Work Item Fields

The default work items in TFS include a lot of information in their fields. Sometimes you may need to include more fields or remove fields so the work items better ft your organization. You do this by using the Process Template Editor. In Figure 5-10, you can see the fields from the PBI in the Microsoft Scrum template; you can see their names, their data type, and their ref name.

If you double-click a field, you are presented with the Field Definition, as seen in Figure 5-11. In this dialog box you can change all aspects of the field itself.

There is the option for you to add different kinds of rules to the field, as see in Figure 5-12. So, if you want, you can control which values can be inserted into the field—and a lot more.

To change the layout of the work item, click the Layout tab (Figure 5-13). This might look a bit complex at first, but after you start experimenting, you’ll find that it’s pretty easy to do a complete makeover if you want.

Select Preview Form to see your changes (Figure 5-14).

Work Item Workflow

There is a workflow you can add to the work items. A Bug work item has a State field, for instance, where the state flows through different levels. In this field, you can set the status of the bug, such as active, closed, resolved, and so on. A typical workflow looks like the one shown in Figure 5-15.

In this example, you can see the workflow for a PBI work item in Microsoft Scrum. This particular work item can have one of five states: New, Approved, Committed, Done, or Removed. The PBI can transition through these states in the following ways:

• New to Approved

• New to Removed

• Approved to Committed

• Approved to Removed

• Committed to Done

• Removed to New

You can also let automatic transitions occur in the workflow. For example, if a closed bug is reopened because of a new test that shows there are still some errors in the code, you can have the bug reassigned automatically to the person who closed it. In this way, you save some work because you don’t have to hunt down that person yourself.

Modifications to the Web Access

So what can you modify in the web access? Well, quite a lot associated with what things look like when you work in the web-based GUI. By clicking the Configure team settings icon in the backlog view, you reach the settings for changing the Kanban board (Figure 5-16).

Doing this opens up a new window (Figure 5-17) in which you can modify the following aspects of the GUI:

• Cards

• Board

• Charts

• General

• Cards

You can change the fields you presents on your cards. Although Microsoft has limited which fields you can show, you still have a fair collection at your disposal.

You can also create style rules that allow you to color-code a card based on a work item query. In this way, you can, for instance, stipulate that all bugs appear in red on the board (Figure 5-18).

You can also color-code a specific tag. Figure 5-19 shows that the tag Blocked is yellow and the tag Database is green. Both of these color codings will be of great use when you want to enhance visibility into your projects.

When it comes to boards, you can add and arrange your columns on the board (Figure 5-20). If you are configuring the Kanban board, you can add a WIP limit, for instance. There is also an option to split a column into Doing and Done. This creates two columns of one, so you can show more easily that a specific PBI is ready for the next step in the process flow. In Figure 5-18, the Develop columns is split using this method and makes visible to testers that a PBI is ready for testing after developers are done working on the functionality. This is a good way to avoid adding a new column or state.

Another thing you can do is add “swim lanes” to your board. For instance, during a project when I worked as a service manager for a large intranet, we used swim lanes to keep track of different issues that came into the support group. Bugs had their own swim lane and CRs had their own as well. In this way, we increased visibility for all in the maintenance team as well as for stakeholders. Swim lanes are basically just rows in a board that can be used for whatever purpose you want—a nice inclusion by Microsoft.

The Charts feature does not provide many options. Basically, you can choose the time interval for the cumulative flow diagram. The default is 30 weeks, you can shorten that time span. You can also choose to include the first and last columns of your board.

There is one last section, which is the General section. From here you can select whether you want to show Epics, Features, and Backlog items in the backlog. For example, in Figure 5-16, you can see that Backlog does not include Epics. By selecting the check box for Epics in Figure 5-21, you can tell Azure DevOps to show Epics.

You can also select the working days you will use during your project. Most people will obviously use Monday through Friday, but you can include weekends as well.

The choice is yours to make. Evaluate which way works best for your team; you can always change it later.

Modifications to the Process Templates in Azure DevOps

In earlier versions of Azure DevOps, it wasn’t possible to change many aspects of a process; you had to use what Microsoft chose for you. These days, however, you have many options to customize you process, which is a great step forward for Azure DevOps.

There still are some differences between the ways you can modify templates. Azure DevOps, for instance, uses a different model than TFS for relating projects and processes. In TFS, process templates are used as starting points for projects and, after a project is created, the project is the scope you customize. In Azure DevOps, a process is shared across multiple projects and this is the scope you customize.

Otherwise, the syntax and structure used in defining a process is basically the same. There are only a few minor differences between templates you customize for Azure DevOps and those you upload to support an on-premises TFS.

Let’s take a look at how you access the process template in Azure DevOps. In Figure 5-22, you can see that you should point to the configuration wheel in the left corner of the interface for the Azure DevOps instance. This brings us to the Organization settings for Azure DevOps, where you can access the processes (Figure 5-23).

The changes you make are made on all projects in the collection, not on a single project. In Figure 5-23, you can see the three default processes from Azure DevOps to work with and the two inherited processes.

To modify a process, you click the process name in the list, but there is one thing you need to consider. You cannot modify any of the three default processes in Azure DevOps. Azure DevOps displays a warning, like the one in Figure 5-24. What you need to do is create a copy (an inherited process) of the process you want to modify.

To do this, click the link in the warning. This opens a new window (Figure 5-25), where you can give the inherited process a name and a description. When you are satisfied, click Create process.

Now you can access the inherited process and start editing. By clicking the three dots (the dots are hidden behind the pop-up in Figure 5-26), you can access the Edit mode.

Click Edit to bring up the edit menu. The first thing you see when you enter Edit mode is the overview of your new process (called New Inherited Agile in Figure 5-27). You can change the name of the process as well as the description.

What can you change while in Edit mode? When you click the inherited process, you can access work item types (Figure 5-28), backlog levels, and projects (showing which projects use the inherited process).

All work item types defined for the chosen process are visible on the left side of the screen. If you click User Story, you enter Edit mode for that work item type (Figure 5-29). For each type, you can change the following:

• Layout

• States

• Rules

You can add new fields, new groups, or new pages for the work item type. Figure 5-30 shows what a sample layout of a user story in the Agile process looks like when you create a new story.

Look closely at the fields in Figure 5-30 and compare them to the fields shown in Edit mode in Figure 5-29. You can edit the bug to include more groups (Status is one group and Planning is another, for example), and add more fields below each group. The groups can be placed in all three columns of groups, as shown in Figure 5-31.

The result can be seen in Figure 5-32.

For each group, you can add, edit, or remove fields, so you can configure the group and enter the information your organization thinks is important for a work item type.

The Fields view lets you add or modify the attributes of a custom field or the attributes of an inherited field (Figure 5-33). Keep in mind that you cannot modify system fields. In the example shown in Figure 5-33, you work only with the fields present in the work item type you are currently editing.

For each custom field, you also have options for each field (Figure 5-34).

Figure 5-35 shows that you can also make some adjustments to where a new fields should appear in the layout.

After you are done editing your process, you can access it and create a new Azure DevOps project using your own customized process, as shown in Figure 5-36.