Work items are an integral part of Team Foundation Server. In this third part of the Microsoft ALM series, you will learn about the possibilities work items can give to your development team. You will also learn when work items are useful and when you might not need them at all.
Team Foundation Server (TFS) contains a feature called work items (WIs for short). These allow the members of the development team to record application requirements, communicate with each other and work in unison with the defined process model for the organization. Work Items are part of every Team Foundation Server team project, and can be created by all team members provided that they have the appropriate user rights.
When adding new work items, the process looks like typing in text to fields in an electronic form. These forms can be filled in directly using Microsoft Visual Studio, or the web-based Team Foundation Server Web Access feature. Work items can also be queried, and the information in them is the basis for many different reports in Team Foundation Server. For instance, if the work items would contain information about bugs, you could run a report estimating the amount of work remaining.
Just like with other features in the Team Foundation Server, work items and the reports associated with them can be customized. For instance, you can add and remove fields from work items, and introduce new types of work items into your team projects. By default, each team project contains several different work item types for reporting bugs, storing application requirements and prioritizing development tasks, and so on.
In this article, you will learn about the work item support in Microsoft Visual Studio 2010 and Team Foundation Server 2010. This article assumes you have basic knowledge of TFS and know how to get around within the product. If you are new to TFS, take a look at the previous two parts of this Microsoft ALM article series available here.
Now, let's start from the basics of work items.
What are Work Items?
Work items store information about planned work for individual members or the team as a whole (Figure 1). Different work item types available in a project are defined by the process template of the team project, and are set when the team project is created. Although certain modifications can be made into an existing team project, it is best to think that the work item definitions become fixed when the team project is created. Technically, work items are stored as records in the Team Foundation Server SQL database.
Figure 1. Work items can be viewed and edited directly in Microsoft Visual Studio.
Table 1 lists the work item types (which are a form of TFS artifacts) available in the two default process models that Microsoft provides. The MSF for CMMI process template defines slightly more work items than the agile template, MSF for Agile.
Table 1. Out-of-the-box work item types supported by Team Foundation Server 2010.
Assuming team members have the rights to do so, each member can file their own bugs and fill in as many as possible of the fields in the work item (the "form"). By default, Microsoft Visual Studio doesn't enforce that many fields to contain a value; instead filling in the fields is left to the team member's discretion.
Although not making most of the fields in the work items mandatory means easier filling in, the problem is that the reports that the system can deliver are only as good as the data the reports are based on. If team members leave out field values just out of convenience or hurry, the reports can only contain partial information at best. As it often is with TFS, it is the organization culture that defines how much benefit can be gained from the system.
Learning to use work items can also mean learning new words, especially for developers that are not native English language speakers. Words like triage, iteration, epic and stack rank might not be immediately obvious in the context of software development.
Furthermore, the debate about priority and triage values is long-lasting: what is "high" priority? By definition, setting a triage is "the process that is used to review newly reported or reopened bugs and assign a priority" and setting a priority is deciding which features should be implemented first.
In addition to being just forms with fields that can be filled in, work items participate in the defined workflow of the team project. This means that certain rules apply to filling in the fields of a work item. For instance, the organization's process model might mandate that a bug fix is verified by a tester before it can be marked as resolved. This workflow is defined as transitions in the process template for the team project.
To facilitate information sharing, Team Foundation Server allows work items to be linked with each other. This allows you to build a "tree" of work items, allowing you to walk from a higher level work item to a more detailed implementation level work item. For instance, in agile methodology, you could link tasks to a user story, or a task to an issue. Work items can be linked together by using Microsoft Visual Studio's Link to command.
How an Organization Could Use Work Items?
To understand how an organization might benefit from work items, and short walkthrough is in order. Assuming you have already created a blank team project based on the MSF for Agile process template, launch Microsoft Visual Studio 2010. In the development tool, open up the Team Explorer window (Figure 2) and expand the Work Items node. You will see a set of queries; by default the work item database is empty, but is easy to add new items.
[Part 3, Figure 2 - Team Explorer.png]
Figure 2. The Team Explorer window is the key access point to TFS functionality. Another alternative is the web access portal.
To add a work item to the team project, use the commands in Microsoft Visual Studio's Team menu. In this menu, there is a command for each work item type available in the current process model. In MSF for Agile's case, the available options are Bug, Issue, Shared Steps, Task, Test Case and User Story. Once you have added work items, the most recently used type appears at the top of the Team menu.
An agile development project should start by defining the user stories: these are the high-level functionality descriptions of type "User <type> needs to <task name> because <reason>". To fill in such a work item, you would select the Team/Add Work Item/User Story menu command, and then start filling in the form. Ultimately, the work item will be added to the currently active team project, selected through the Team Explorer window.
Often, only a title is mandatory, but the more fields can be filled in, the better. For instance, reporting and work item querying is improved if the fields have been filled in. In a user story, you should at minimum fill in a description (which can be improved as the projects moves onwards), area and the iteration. To estimate the work load, you should also fill in the Story Points field. This is a best guess about the involvement needed to finish the story.
To complete the work item, click the Save Work Item button at the top. Internally, a work item has a numerical ID which is unique among the whole team project collection. You will learn about project collections shortly; at this point you can think of a team project collection to be a similar thing for team projects as a Microsoft Visual Studio solution is to code projects.
Once you have a user story defined, you should create task items to contain information about the story implementation. For instance, you might want to create three tasks for things like setting up a database, starting a code project, and adding logic to connect to the database. These tasks should be linked to the user story.
To create a linked work item, first open the work item that should be the base work item (the one to which you wish to link). You will learn how to query work items in the next section, but at this point, assume you already have the correct base work item open. Then, go to Microsoft Visual Studio's Team Menu, and select the Add New Linked Work Item command. If you instead already have two work items but wish to link them, open either one, go to the All Links tab, and click the Link to button. The will open the dialog box titled Add Link To, shown in Figure 3.
[Part 3, Figure 3 - Linked Work Item.png]
Figure 3. Linking work items is useful in building trees and collections of work items that share a common goal.
In this dialog box, you can select a link type, which allows you to link the work item to many different object types. This includes changesets (version control changes), parent items, predecessors, and so forth. To follow the example of a user story and three linked tasks, you would create the links using this dialog box.
Sometimes, especially when starting a project or doing quick-paced development, there might be a need to edit or add multiple work items rapidly. For this reason, Team Foundation Server provides integration with both Excel and Microsoft Project. In Microsoft Visual Studio, you can click a button to open a set of work items in Excel (Figure 4). Excel will then open and show the work items, allowing you to work with multiple work items quickly (Figure 5).
[Part 3, Figure 4 - Open in Excel.png]
Figure 4. Work items can be edited in Microsoft Excel and Project.
[Part 3, Figure 5 - Excel.png]
Figure 5. The Team tab on the Excel ribbon contains commands to work with work items.
Querying Work Items
So far, you've learned how you can add new work items. But since Team Foundation Server is about team collaboration, chances are that somebody else has also added new work items to the project that you need to work with. To find those, you would execute a query that returns a set of work items.
In TFS, a query is a predefined set of conditions with which the active set of work items is iterated through. For instance, you could have query called "My Bugs" which would run a query that returns all active bug work items that have been assigned to the current user (see again Figure 2). TFS also supports so-called team queries. These are team-wide query templates that return for example all active bugs, no matter to whom they have been assigned to.
Both query types can be accessed through the Team Explorer window in Microsoft Visual Studio (they are also available through the web access feature of TFS). Every developer can create their own queries, and customize the existing ones. When editing the queries, Microsoft Visual Studio provides a simple grid-based editing experience, but internally, the queries contain SQL like syntax.
When you double-click a query in the Team Explorer window, Microsoft Visual Studio will open a query results window which shows a list of the matching work items (Figure 6). Then, by double-clicking a work item on the list, you can open it and start editing the fields in it.
]Part 3, Figure 6 - Query.png]
Figure 6. Work items can be queried with multiple built-in templates.
Remember that Microsoft Visual Studio will keep a history log of every change to the work item. You can view this history through the History view on the main tab (see Figure 7). It is possible to type in comments or notes directly into the History view. This is useful in case you want to describe for instance the reasons behind a change.
[Part 3, Figure 7 - History.png]
Figure 7. Each work item change is collected into a history log, along with optional user comments.
Furthermore, you can assign alerts to work items, so that you can receive an email if a particular work item changes. This is a useful feature especially for higher-level developers, architects and project managers.
Work Items and Project Collections
Team Foundation Server 2010 brought a new feature called team project collections. Team project collections make it easier to manage multiple team projects using common settings, and administer these team projects collectively. However, a team project collection is also an information boundary. Outside the collection boundary, information such as work items cannot be shared - this is by design. Technically, each team project collection lives in its own SQL Server database.
Although not a requirement, it is common that work items in team projects share some common functionality. Within a team project collection, you could share work items between team projects. For instance, if you were building both a desktop and a web version of the same application, you could be sharing the user story work items.
Sharing saves time because you don't need to type in the work items twice. To share work items, linking them is the most efficient way. There is also an option to copy work items, so that you can quickly create a new work item based on a previous item.
Each individual work item in TFS can be pointed to by a direct URL. With this functionality, you could send a link to a particular work item for example via email. To do this, simply click the Outlook icon in the work item view. This will open the default email application on the system, and insert an HTML table with a link to the work item. The link will point to the web access page displaying the particular work item (Figure 8).
[Part 3, Figure 8 - Web Access.png]
Figure 8. The web access feature allows working with work items, among other things.
Team Foundation Server work items are a highly useful method for collecting requirements, task and bugs (among other information) about a development project. Work items are also the basis of Team Foundation Server reporting, and if properly filled, they can collectively provide a clear indication of where the project currently stands. Thus, work items benefit all members of the team: developers, testers, architects and project managers.
Microsoft Visual Studio contains nice integration with work items, and you can also work with them using the web access feature. Work items are beneficial for every project except maybe the tiniest ones. Indeed, if your project only lasts a day or two, you might not want to spend time adding work items: you could probably code the whole application with the same effort. But for anything larger, work items quickly become indispensable.
Microsoft has placed lot of effort in making Microsoft Visual Studio a premier client for work item manipulation. However, sometimes a more direct approach is useful, and this is when the Office integration becomes useful. Especially the ability to work with Excel to edit and add work items offline allows project managers to take their laptop and travel to the customer to discuss requirements together. When back at the office, changes can be uploaded to the server.
That's what could be called dependable technology.
This article was the third part in the Microsoft ALM series about Team Foundation Server 2010. The first part is available here. The fourth part will focus on testing.