Work Item Types

You can use the work item types that Microsoft ships with VSTS in the three templates. But as mentioned earlier, we think you should really consider your own needs in the organization and make adjustments to these. Your organization might need more work items or might need to extend the information required for them. If your project managers 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? Which states can a bug transition between? Microsoft supplies a set of default work item instances when a project is created. These 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 ALM process need? In Figure 5-4, you can see the queries of the MSF for Scrum.

Figure 5-4. The work item queries in the Scrum process

Reports

This is something that most of our customers have modified. The reports in the processes are very good. Figure 5-5 shows one of them, representing how much work is left in a project. In choosing which reports and information you need, we once again come back to the fact that this is something that you need to discuss with your project teams and also 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?

Figure 5-5. One of the reports showing remaining work in the project

Areas and Iterations

Areas and iterations are interesting concepts. Iterations are just as they sound, 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 that is up to you to decide. You can nest these 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 later be labeled with both an area and an iteration. Depending on your ALM process, you might use this for various reasons. If you run a project using RUP, you might want to use the iterations by naming them after the phases of RUP. Then you can nest iterations below each phase 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.

Figure 5-6. Areas and iterations in the team settings

It is all up to you what you want to use these two categorizations for. In our opinion, they are very useful. They give you an enormous freedom in how you set up your projects, so we suggest you make good use of them.

Modifying Work Items

Microsoft encourages you to modify your process template. One important thing we have found worth modifying are the work items. Many organizations we have seen have needed information in their work items that is not available in the three Microsoft templates. In those cases, we have adjusted the work items to better fit in the organization. This has turned out very successful in all cases. One thing we have changed is the workflow of the work items.

How to Open the Process Template

You could 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 (see Figure 5-7) and choose Process Template Manager below Team Project Collection.

Figure 5-7. Starting the Process Template Manager from Team Explorer

Select a process template for downloading and click on Download in the Process Template Manager (Figure 5-8). Select a location to download the process template. Close the Process Template Manager when you are done.

Figure 5-8. Selecting a process to download

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

Figure 5-9. Starting the Process Editor from Visual Studio

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

Work Item Fields

The default work items in TFS include a lot of information in their fields. But sometimes (quite often) we need to include more or maybe remove some fields so that the work items better fit our needs. You can do this by using the Process Template Editor. Figure 5-10 shows the fields from the product backlog item in the Microsoft Scrum template. You can see their names and what data type they are, and also the Ref Name.

Figure 5-10. The fields in the PBI WI from the Microsoft Scrum template

If you double-click on a field, you are presented with the Field Definition as seen in Figure 5-11. From this window, you can change all aspects of the field.

Figure 5-11. Field Definition window

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

Figure 5-12. An example of a workflow for a bug work item

To change the layout of the work item, you use the Layout tab (Figure 5-13). This might look a bit complex at first but once you start experimenting you will find that it is pretty easy to do a complete makeover if you want. Select Preview Form to see your changes (Figure 5-14).

Figure 5-13. The Layout tab for work items

Figure 5-14. Previewing the layout

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. It can be active, closed, resolved, and so on. A typical workflow can look like Figure 5-15.

Figure 5-15. An example of a workflow for a PBI work item

In this example, you can see the workflow for a bug work item in Microsoft Scrum. This particular work item can have one of several states: New, Approved, Committed, Done, or Removed. The bug 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 a new test shows there are still some errors in the code, you can automatically have the bug reassigned to the person who closed it. This way, you can 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 how things look when you work in the web-based GUI. By clicking on the Configure Settings icon in the backlog view, you reach the settings for how you can change the Kanban board (Figure 5-16).

Figure 5-16. Configuring the Kanban board

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

• Cards

• Board

• Charts

• General

Figure 5-17. Configuring the Kanban board

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

You can also create style rules that allows you to color-code a card based on a work item query. This way you can for instance determine that all bugs are colored red on the board (Figure 5-18).

Figure 5-18. Bugs are colored red using a style rule

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

Figure 5-19. You can color-code tags as well

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

Figure 5-20. Configuring columns on the board

Another thing that you can do is add swimlanes to the board. For instance, in a project where I was working as a service manager for a large intranet we used swimlanes to keep track of different issues that came into the support group. Bugs had their own swimlane and change requests had their own as well. This way we could increase the visibility for all in the maintenance team as well as for stakeholders. Swimlanes are basically just a row in the board that you can use for whatever purpose you want. A nice inclusion by Microsoft.

Should you need to, you can also change the way work items are reordered on the board. You have two options:

• Work items reorder when changing columns, and the backlog reflects the new order

• Work items follow the backlog order when changing columns

The Charts section does not give you many options. You can basically just choose the time interval for the cumulative flow diagram. The default is 30 weeks but you can shorten that time span if you want.

Then we have one last section, which is the General section. From here you can select if you want to show epics, features, and backlog items on the backlog. In Figure 5-16, you can see that the backlog does not include epics, for instance. By selecting the Epics checkbox in Figure 5-21, you can tell VSTS to show epics as well.

Figure 5-21. Showing epics on the backlog

You can also select which working days you use in your project. Most will obviously use Monday to Friday but you can include weekends as well.

The last thing you can change is the way bugs are handled on the backlogs . There are three options:

• Bugs appear on the backlogs and boards with requirements

• Bugs appear on the backlogs and boards with tasks

• Bugs do not appear on backlogs and boards

The choice is yours to make. Try which way works for your team; you can always evaluate and switch later.

Modifications to the Process Templates in VSTS

In earlier versions of VSTS it wasn’t possible to change many aspects of the process. You were stuck with what Microsoft had chosen for you. These days, however, you have many options to customize the process, which is a great step forward for VSTS.

There still are some differences between the ways you can modify the templates. VSTS for instance uses a different model than TFS for relating projects and process . In TFS, process templates are used as starting points for projects and once a project is created, the project is the scope you customize. In VSTS, on the other hand, a process is shared across multiple projects and that is the scope you customize.

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

Let’s take a look at how you access the process in template in VSTS. In Figure 5-22, you see that you should point at the configuration wheel in the top corner of the interface. When the configuration page is opened the first thing you need to do is to select the default collection in the top-left corner as seen in Figure 5-23.

Figure 5-22. Accessing the configuration of the process in VSTS

Figure 5-23. To see the processes in your VSTS instance, make sure you select the default collection

As you can see, these changes are made on all projects in the collection and not on a single project. In this figure, you can see that you have the three default processes from VSTS to work with.

To modify a process you click on the process name in the list. But here is one thing you need to consider. You cannot modify any of the three default processes in VSTS. VSTS will show a warning like in Figure 5-24. What you need to do is create a copy (an inherited process) of the process you want to modify.

Figure 5-24. You cannot modify any of the three system processes

You do this by clicking on the link in the warning. This opens up a new window (Figure 5-25) where you can give the inherited process a name and a description. Once you are satisfied, you click Create Process .

Figure 5-25. Creating a shared process for editing

Now you can access the inherited process and start your editing. The first thing you see when you enter edit mode is the overview of your new process (called My Own Custom Agile in Figure 5-26). As you see, you can change the name of the process as well as the description. If you look closely you can also see that you can check a checkbox that allows you to create new projects based on the inherited process and also allow users to change existing projects to use this process. This is a very nice feature in some cases.

Figure 5-26. Starting editing the inherited process

What can you change while in editing mode? If you look at the Work Item Types tab (Figure 5-27), all work item types defined for the chosen process are visible on the left side of the page. For each type, you can change the following:

Figure 5-27. Attribute s in the overview view is read-only at this time

• Overview

• Layout

• Fields

The overview shows the name of the work item type as well as the color coding the work item type has. In Figure 5-27, you see the bug work item type and the fact that it will be displayed with a red color coding. At the time of writing it is not possible to change any of the information here but I suspect Microsoft will add this possibility later on.

Moving on to the layout. Figure 5-28 shows what the layout of a bug in the agile process looks like when you create a new bug. Look closely at the fields in the figure and compare them to the fields you can see in editing mode in Figure 5-29.

Figure 5-28. The bug form in the agile process

Figure 5-29. Editing the bug work item type

You can edit the bug to include more groups (Status is one group and Planning is another for instance) and add more fields below each group. The groups can be placed in two columns of the three columns of groups that Microsoft provides, as Figure 5-30 shows. You cannot place a new group in the first column.

Figure 5-30. Adding a new group on the bug work item typ e

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

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

Figure 5-31. Working with fields in edit mode

Figure 5-32 shows that you can list all fields in the entire process so that you can get an overview of them, including system fields and fields from the parenting process. In this view you can see which user story uses a specific field.

Figure 5-32. You can list all process fields and see which work item type includes the field

You can also see that you have a security tab that you can use. In this view, you can select which TFS users are allowed to create or modify the processes in your VSTS instance.

Once you are done editing your process, you can access it and create a new VSTS project using your own customized process, as shown in Figure 5-33.

Figure 5-33. After you have created a custom process, you can use it to create a new VSTS projec t