Support for Work Item Tags in TeamCompanion

You have been waiting long enough: just update your Team Explorer to Update 3 of the 2013 version and you will immediately get the support for Work Item Tags in TeamCompanion!

Work Item Tags are one of the never features in TFS which provides you the option to additionally categorize and filter your work items. Work items are easily tagged using the work item form in Team Web Access or in Visual Studio. Tags can then be used for filtering in project backlogs and work item query views.

After you update your Team Explorer to Update 3 of the 2013 version, you will immediately get the support for Work Item Tags in TeamCompanion. Tags are visible in the work item query result list and managed on the work item form.

TeamCompanion supports Work Item Tags

Filtering on tags in TeamCompanion works differently than in Team Web Access.

The TeamCompanion’s full text search applies to work item tags as well, and is precise enough most of the time. If you explicitly want to filter on a tag, you just need to be a bit more specific and use the syntax of the advanced search using work item fields in format: [Tags]=value.

TeamCompanion Includes Work Item Tags in Full Text Search Results

 

Tags are also available in the product and iteration backlogs.

TeamCompanion Shows Work Item Tags In Product and Iteration Backlogs

 

We wish you happy tagging in TeamCompanion!

Using Web Access pages as Team Project Homepages in Outlook

TeamCompanion can use any web page as the Team Project homepage embedded in Outlook. This feature allows you to display any of the pages from your project’s Team Web Access directly in Outlook.

The following set of pictures displays how several interesting Web Access pages can be used as project homepages in TeamCompanion for a Scrum based project, and which Project Home Page Configuration options you need to use:

  • the Team Web Access Home page (Choose “Use Web Access”);

Web Access Home Page as TeamCompanion's Project Homepage

Web Access Sprint Taskboard as TeamCompanion's Project Homepage

Web Access Work Item Query Chart as TeamCompanion's Project Homepage

 

The following error is a known issue when using any Web Access web page as TeamCompanion’s project homepage :

Visual Studio Online does not support your browser. Please upgrade to a supported browser to ensure a fantastic experience! Learn more.

Error Displaying Web Access Pages as TeamCompanion's Project Homepage

To work around this issue you need to edit your registry in the following way:

  • Close Outlook
  • Open regedit and open the key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION
    (If such registry path does not exist on your computer, add all necessary keys to create it.)
  • Add a new DWORD value named “outlook.exe” with following value:
    • If you have Internet Explorer 11 installed: 11000 (0x2AF8)
    • If you have Internet Explorer 10 installed: 10000 (0x02710)
  • ¨Start Outlook

Registry Setting For Correct Display Of Web Access Pages In Team Companion

These setting will make Internet Explorer emulated inside Outlook work correctly. For further details please see http://msdn.microsoft.com/en-us/library/ie/ee330730(v=vs.85).aspx#browser_emulation.

Tip: The easiest way to enter this registry entry is to copy the following text in a text file, save it with a .reg extension, and double click it to add the settings to the registry. Windows will warn you that it is potentially dangerous action and ask whether you want to continue. Please answer yes and the error message will be gone.

        Windows Registry Editor Version 5.00 
     [HKEY_CURRENT_USER\Software\Microsoft\Internet 
     Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION] 
     "outlook.exe"=dword:00011000

If you have any further problems regarding this feature, please don’t hesitate to contact us!

TeamCompanion 5.2 Update 1 Released

TeamCompanion v5.2 introduced the support for role-based work item views for Outlook 2010/2013 and Team Explorer 2012/2013. This v5.2 Update 1 is primarily targeted to enhance this support by introducing more powerful features for managing multiple role-based work item views.

Enhanced Support for Multiple Role-Based Work Item Views

TeamCompanion now provides the option to quickly switch between the default work item view for a user/role and additional alternative views. Some project roles need multiple different views for the same work item type depending on the context of their work. A development lead, for instance, could use an overview view by default, giving him just a subset of all information available in the work item. When discussing work items with developers, he can easily switch to the full view and access all information.

The supplementary administrative tool has been enhanced accordingly, so that now each role-view mapping, in addition to containing the name of the view used by default, can contain the list of additional views. In this case, an additional dropdown named Layouts appears on the work item form, which contains the list of all views available for the user. This list is defined by the current work item type definition and the definition of default and multiple views in the role-view mapping.

Work item form with layouts dropdown containing the list of available role-based views

 

Additionally, we have added precise view resolution rules. In other words, now you can prioritize entries in the role-view relationships table. TeamCompanion will always apply top positioned entries first.

More in depth details about managing and configuring default and multiple role-based work item views are available here.

Removed error causing the reset of TeamCompanion settings during Outlook upgrade

Local user settings, including work item mapping customizations, were reset to factory settings when certain Outlook updates and service packs were installed. This is no longer the case and settings are now preserved between different Outlook versions.

Managing Role-Based Work Item Views

TeamCompanion v5.2 introduced the support for multiple role-based work item views. Members of each user role get only the subset of work item information necessary for their work. By providing simplified views specific to different groups of users, TeamCompanion optimizes the work item user interface, simplifies it and supports a much more efficient work experience. With such an efficient user interface even the novice users can work effectively from the very beginning.

This blog discusses in more detail how to define role-based default and multiple views for different users and groups and what rules are used when a user belongs to multiple groups for which you have defined different views. It explains properties and configuration details from a technical point of view and is aimed primarily at project administrators.

TeamCompanion allows you to create different role-based views for work item forms. For example, you could have a high level overview view for your business stakeholders, which contains only a small subset of all work item fields they want to focus on, namely fields related to business value and schedule. Further views can be used by different types of subject-matter experts (SME) interested in specific aspects of the work item (e.g. specifics of the business scenario a work item relates to, quality and testing or perhaps details related to release management). The default view showing all data would be suitable for the core development team, which still needs access to all technical details.

Team administrators are provided with the supplementary tool to centrally manage role-based views for each team project (available as separate download for TFS 2012and TFS 2013). Using this tool you can define role-view mappings on three possible levels:

  • per user,
  • per TFS group, and
  • per active directory domain group.

To create an entry in the role-view relationships table, first choose a user or a group using the Add button. Then click in the corresponding cell in the column Default Layout Name to edit it, and manually enter the exact name of the view as specified in the work item type definition.

Supplementary tool for central management of role-based work item views

Basic Rules

The default view is used to display all work item types for users who:

  • do not belong to any group for which role-view mappings are defined,
  • have no directly assigned role-view mappings.

Note: The default view comes from the default work item form view which always exists in the work item type definition and is used by other TFS clients such as Team Explorer or Team Web Access.

Only one role-view mapping entry for each user and group can be added to the table.

When a user or a group has a role-view mapping defined, TeamCompanion does the following when deciding how to display each work item:

  1. If the work item type definition contains the view matching the one stated in the Default Layout Name column, then this view is used.
  2. If the work item type definition does not contain the view matching the one stated in the Default Layout Name column, then the default view is used.

After a user or group is assigned a view, they need to (re)start Outlook for these settings to apply.

Defining Views over More Work Item Types

A simplified view targeted to a particular group of users, for example business stakeholders, may be used in several work item types. In other words, a stakeholder using a high level overview for a User Story, will need a high level overview for a Task as well. As a consequence of the basic rules stated above, you can achieve this is in the following way:

  1. Edit the definition of the User Story work item type and define a custom user story view for your stakeholders. Let’s name it Stakeholder View.
  2. Edit the definition of the Task work item type and define a custom task view for your stakeholders. Name it using the same view name as in the User Story, Stakeholder View.
  3. Add an entry to the role-view relationships table, specifying the group your stakeholders belong to (or a particular stakeholder) and reference the Stakeholder View in the Default Layout Name column.

Note: The number of views defined within each work item type definition is not limited.

Using Multiple Views

Until now we have explained how the view stated in the Default Layout Name column is used as the view of choice for the corresponding user or group referenced by the role-view mapping.

Some project roles can use multiple different views for the same work item type. A development lead, for instance, could use an overview view by default, giving him just a subset of all information available in the work item. When discussing work items with developers, he can easily switch to the full view and access all information.

TeamCompanion provides the option to use such multiple views as well. Alternative views are defined in the column Other Layouts as a semi-comma separated list of work item type view names. The default work item type view is referenced using the syntax {Default}.

The following example references the default view and another 2 views:
{Default};All in view (Devs);Just the content view (SME)

To add multiple views to an existing entry in the role-view relationships table, click in the corresponding cell in the column Other Layouts to edit it, and manually enter the semi column separated list of view names.

Supplementary tool for central management of role-based work item views

When a role-view mapping contains the definition for multiple views, then an additional dropdown control named Layouts appears in the toolbar of the work item form. It contains the list of all views available for that user. This list is defined by the current work item type definition and the definition of default and multiple views in the role-view mapping.

Work item form with layouts dropdown containing the list of available role-based views

 

More precisely, the list in the Layouts dropdown is an intersection of the set of views from the work item type definition and the set of views which is the result of the union of the default and all multiple views defined in the role-view mapping.

The following table contains a few examples to clarify there rules:

Process Template:
Views in the
work item type definition

Admin Tool:
Default Layout Name
column

Admin Tool:
Other Layouts

column

TeamCompanion:
Layouts

dropdown list

{Default}
All in view (Devs)
High level overview (CxO)
Just the content view (SME)

All in view (Devs)

{Default}
High level overview (CxO)
Just the content view (SME)

{Default}
All in view (Devs)
High level overview (CxO)
Just the content view (SME)

High level overview (CxO)

All in view (Devs);

All in view (Devs)
High level overview (CxO)

{Default}

High level overview (CxO)

{Default}
High level overview (CxO)

All in view (Devs)

High level overview (CxO)
View_A

All in view (Devs)
High level overview (CxO)

All in view (Devs)

View_A
View_B

-

As you can see from the examples, for work item types containing at least one of the multiple views, the Layout dropdown will be visible. The dropdown will not appear when just a single view is valid for the work item type after resolving all rules.

Note: In case the view specified in the Default Layout Name column does not exist for a work item type, then the default view for that work item type will be used, no matter it the type contains any of the multiple views.

View Resolution Rules

More than one entry from the role-view relationships table can apply to a single user. For example, a user can have directly assigned role-view mappings and he can be a member of the group which has its own role-view mapping. Or a user can be a member of two groups both having their own role-view mappings assigned.

In order to define which views are valid in such cases, TeamCompanion offers the option to prioritize entries in the role-view relationships table. Using the up and down arrows on the left of the table, the order of table entries can be adjusted.

TeamCompanion uses following rules for view resolution:

  • Top positioned entries are resolved first.
  • If more entries apply to a single user, then only the highest prioritized mapping will be used. Other mapping will be ignored.
  • When the order of entries in the role-view relationships table is changed, then users will get new mappings after they restart Outlook.
    Note: Depending on the order of performed actions, the first displayed view will most probably be the old one (from the cache). Once validated against server, new view will be used instead.
In the following example, Julia has a particular view mapped to her user credentials. In the same time she is a member of the TFS Development Team. In this case, TeamCompanion will use the Julia’s View.
    User/Group Default Layout Name
    Julia Ilyiana Julia’s View
    TFS Development Team Team View

In case the order of the views is changed, as in the following table, TeamCompanion will use the Team View for Julia.

    User/Group Default Layout Name
    TFS Development Team Team View
    Julia Ilyiana Julia’s View

In the following example, Julia is member of both TFS groups, Development Team and Web Team. As the mapping for the Development Team is listed first in the table, TeamCompanion will use the Team View for Julia.

    User/Group Default Layout Name

    Development Team

    Team View

    Web Team Web View

If you have any further questions regarding the management of role-based work item views, please don’t hesitate to contact us!

Check Out our Demo Videos!

We have recently published a series of DemoMate based demos about various usages of TeamCompanion.

Following demos are available on our website:

  Work Item from Email

Despite collaboration tools, mail communication is still necessary. Very often emails must be converted into work items. In this demo you will see how TeamCompanion makes this conversion easy, helps report status using so called "Done emails" and finds a work item related to a specific email and opens it in an instant.

   Querying and Filtering

TeamCompanion offers rich support for creating and executing standard and custom work item queries. By executing queries automatically and highlighting the changed work items, TeamCompanion provides instant notifications about changes. This demo shows all these features from the perspective of three different roles within the development organization.

  Work items as the first class Outlook items

This demo shows that with TeamCompanion, Outlook treats work items with equal care with which it treats emails: multi-level grouping, full text search, creating a reminder for a work item or flagging it as a to-do item is easy. Scheduling an appointment to discuss a work item is also easy.

  Offline What-If Analysis

Scrum is no stranger to TeamCompanion. It offers native support for the drag and drop based backlog management, sprint planning, capacity planning and load balancing within the team backed by real time charts. Real time burn down chart helps with the day to day task tracking. All of this includes offline what if analysis: work out different options without saving anything on the server and commit just to the final plan.

  Feedback Request

TeamCompanion fully integrates feedback request/response workflow, so that you can ask for and give feedback during different phases of the development process.

 

Demos use the lightweight interactive DemoMate format (Silverlight-based), which simulates the experience of interacting with live software in a click-through linear style. You can preview demos in 2 modes:

  • Presentation: the demo advances automatically, while you listen to the narration and follow the actions on the screen.
  • Training: you advance through the demo manually by clicking on particular spots on the screen.

Both modes allow you to go full screen and preview click instructions and the presenter script in a heads up display. This is especially useful for the Training Mode, because it enables the user to learn and practice each demo with click-by-click instructions visible on the screen.

All demos can be previewed online (without audio) and can be downloaded and installed for offline usage.

We hope you will enjoy this interactive experience and learn even more about how TeamCompanion can help you and your team deal with everyday challenges.

TeamCompanion: The One and Only TFS Client

TeamCompanion is the ideal primary TFS client for all non-technical stakeholders on your project, from C level managers to information workers. The newest enhancement to our rich feature set is unique among TFS clients, and allows you to configure different work item user interfaces for different project roles. This way, your business stakeholders can get a simplified work item view containing only specific information they are truly interested in, and leaving all excessive details out of their primary focus. 

Note: Contents of this blog entry were updated after the release of TeamCompanion 5.2 Update 1.

Work items are core artifacts used to achieve traceability over your entire application lifecycle supported by TFS and thus contain a wealth of data. As different project roles use work items in many different scenarios, usually what they really need are particular subsets of this data. For many non-technical users, the standard web client and the user interface for TFS is inefficient, too complex and even intimidating. Excessive detail presented on the default work item form turns out to be very confusing, bogging them down and keeping them from focusing on the main points.

Simplify Work Item User Interfaces to Better Suit Different Project Roles

TeamCompanion implements a unique feature, unavailable in other TFS clients, which allows you to create different role based layouts for work item forms. In other words, you can create simplified work item views for your business stakeholders, which contain only specific work item fields they want to focus on. Thanks to this powerful enhancement, TeamCompanion qualifies as the primary client for Team Foundation Server or online Team Foundation Service for all your non-technical users, more suitable than Team Explorer and Web Access.

The following pictures show the same work item of type Epic displayed using two different views. The top picture shows a view containing all work item fields compared to the simplified view shown on the bottom picture.

View of the Epic work item form with all fields

Simplified view of the Epic work item form showing a selection of fields

Notice that the simplified view gives a high level overview of the Epic, containing a selection of status fields and its description. It is therefore suitable for all project stakeholders interested only in the “big picture”. The default view contains all data and is suitable for the core development team, which still needs access to all technical details.

Managing Role-Based Work Item Views

Work item views are part of work item type definitions and are managed on the TFS server as part of your team project template.

Role-view mappings for TeamCompanion are managed centrally by team administrators using a special supplementary tool. Mappings can be defined on the level of TFS groups, domain groups as well as particular users. Such centralized control releases end users of any burden regarding configuration and administration of views, allowing them to exclusively focus on their work. Once a user or group is assigned a view, they simply need to (re)start Outlook and continue working.

TeamCompanion decides how to display each work item in the following way:

  1. When a user does not have a directly assigned role-view mapping and does not belong to any group which has a role-view mapping assigned, then the default work item view (which always exists in the work item type definition) is used.
  2. When a user has a directly assigned role-view mapping or she belongs to a group which has a role-view mapping assigned, then:
    • If the work item type definition contains the view matching the one stated in the role-view mapping, then this view is used.
    • If the work item type definition does not contain the view matching the one stated in the role-view mapping, then the default view is used.

A simplified view targeted to a particular group of users, for example business stakeholders, may be used in several work item types. In other words, a stakeholder using a high level overview for a User Story, will need a high level overview for a Task as well. To achieve this, you need to add views with identical names in work item type definitions for all work item types you want to simplify.

Some project roles can use multiple different views for the same work item type. A development lead, for instance, could use an overview view by default, giving him just a subset of all information available in the work item. When discussing work items with developers, he can easily switch to the full view and access all information. TeamCompanion provides the option to use such multiple views as well: each role-view mapping contains the name of the view used by default and can contain the list of additional views. In this case, an additional dropdown named Layouts appears on the work item form, which contains the list of all views available for the user. This list is defined by the current work item type definition and the definition of default and multiple views in the role-view mapping.

More in depth details about managing and configuring default and multiple role-based work item views are available here.

TeamCompanion is Best Suited for Everyone’s Tasks

Simplified work item views suited especially for non-technical users are a powerful enhancement to the existing TeamCompanion’s rich feature set.

TeamCompanion lets you connect to multiple TFS servers, project collections and team projects simultaneously, allowing you to interact seamlessly with all of them. It keeps your whole team on the same page, improving communication and collaboration among team members. By combining Outlook artifacts such as e-mails, appointments or reminders, with TFS artifacts like work items, work item queries or reports, it successfully bridges the gap between the worlds of business stakeholders and development teams.

This is a must-have tool that provides for increased productivity for all Outlook and TFS users. It offers many advanced ways how to accelerate and optimize your work item management tasks and stay up to date with latest project developments. With TeamCompanion you can manage your team projects with least context switching and by using the smallest possible number of tools for your daily tasks.

Additionally, TeamCompanion delivers a powerful agile project management feature set with an emphasis on native support for Scrum. It helps you to competently manage teams and their backlogs, load balance resources and track progress.

TeamCompanion is the one and only TFS client tool you need to unleash the power of your Team Projects, no matter your role in the development process.

With this last post in 2013, we wish you happy holidays and a successful New Year, in which your development teams, backed up by TeamCompanion, will achieve great result.

Using Project Policy to Control the Conversion Between Outlook and TFS objects for the Whole Team

Configuration settings regarding the conversion between Outlook and TFS objects which are now managed per team project, can be put in place in form of a project policy, in which case they are automatically distributed to all team member using TeamCompanion. This means that TeamCompanion will behave in the same way when any team member performs an action covered by these settings.

Productivity in daily tasks is all about small tricks and enhancements. Imagine that all mails originating from work items which circulate between your team members used the same formatting? Imagine that, when someone sends you a bug, you could quickly find a particular information like bug severity just by scanning the email? Or that all bugs created from emails followed the same layout?

In this post we will talk about how your team can use a single set of configurations put in place in form of a project policy. You will learn how TeamCompanion can help your team unify the structure and layout of information you all come across daily while working in between TFS work items and your email folders.

Turning on a Project Policy

In our previous post, we described new features introduced with TeamCompanion v5.2, which allow you to manage configuration settings for conversion between Outlook and TFS objects per team project, and to configure conversion rules separately for each work item type. 

Only project administrators have the right to manage project policies. In comparison with users without administrative privileges, they see two additional controls on the Project Settings tab, which are used to manage project policies: the checkbox Set as project policy, located in the Server/Project group, and the button Save to Server, located next to the Reset button on the bottom of the tab.

A project administrator will first configure and tests the desired set of rules locally, handling these as a local customization available only for himself. Once he is satisfied with the rules, he will turn them into a project policy in the following way:

  1. He will check the checkbox Set as project policy and,
  2. He will click on the button Save to Server.

Note: A project policy is set only after performing both these steps!

Turning On A Project Policy

Distribution of a Project Policy

Configurations put in place as a project policy are automatically distributed to all team member using TeamCompanion. Everyone will automatically retrieve these settings next time they start Outlook or when they connect to a team project.

The Project Settings tab for users without administrative privileges will look like on the following picture. They will see the note “Project settings locked for editing by TFS administrator.” and all controls on this tab and all sub-tabs will be read only. Such users will be able to explore policy rules, but not change them. They can not set any local preferences in case a policy exists. The Reset button will manually retrieve current policy settings from the server.

Users without administrative priviledgles cannot change policy settings.

Project administrators will retrieve policy configurations the same way as users without administrative privileges, but they will have the option to change policy settings, as described in the following chapter.

Note: Project policy settings are retrieved each time you start Outlook.

Shared editing of policy settings by project administrators

Each project administrator can manage project policy settings. After a policy is put in place, configurations are automatically retrieved from the TFS server and available for further editing.

A project administrator can further explore different configuration options locally. He can change a settings, close the Options dialog and thereby save this change only locally. If he wants to reset his changes and return all values to match the actual project policy saved on the server, he can accomplish this by clicking on the Reset button. When he has tested his changes, he can save them as an updated project policy by clicking on the button Save to Server.

Note: If an administrator closes Outlook without saving his changes to policy settings to the server, when he starts Outlook next time, his local changes will be automatically reset to values saved on the server as the current project policy!

To reset a project policy to default values got when installing TeamCompanion perform following steps:

  1. Uncheck Set as project policy and click on the button Save to Server (this will remove the project policy),
  2. Click on the button Reset (this will reset local settings to default values),
  3. Check Set as project policy and click on the button Save to Server (this will save the reset settings as project policy).

Note: Examples in this blog are based on the Brian Keller’s Visual Studio 2012 RTM ALM Virtual Machine, which has been upgraded to Office 2013, Visual Studio and TFS 2013 RC and expanded with TeamCompanion 5.2. RTM.

Bridge the connection between Outlook and TFS items the way it suits your needs

The deep integration of Outlook and TFS is one of the major features TCO offers from its early beginnings. Work items can be easily transformed into Outlook mails, tasks, appointments and remainders and vice versa, where TeamCompanion takes care of the easy transition of data between them and tracks their relationships.

Configuration options regarding conversion between Outlook and TFS objects were highly configurable in previous versions as well. What we previously lacked was the possibility to set boundaries for your configuration settings which match team project boundaries. In other words, if you defined any kind of special rules, these were applied to all team projects you accessed using TeamCompanion..

The newest version 5.2  brings two major improvements to these feature:

  1. Now we allow you to manage configuration settings for conversion between Outlook and TFS objects per team project, so that different team projects can use different configurations.
  2. Conversion rules are now configurable separately for each work item type.

This post brings you a detailed description of these features.

Additionally, project settings can be put in place in form of a project policy, in which case they are automatically distributed to all users. This feature is described in a separate blog post.

Redesigned Options Dialog

The Options dialog has been redesigned and it now contains a single tab named Project Settings, which contains all settings related to the conversion between Outlook and TFS objects.

In the Server/Project group you define the team project for which the rules will be applied. The dialog initially shows the default team project.

In the Work Item Type group you choose the work item for which you are creating a distinct configuration. By adding and removing work item types, you control how the conversion will behave for different work item types.

We have not changed the functionality contained within tabs Send Email, Create WI from Mail, Create Task, Create WI from Task, Create Meeting Request and Create WI from RSS. The rules you define there are now simply applied to the combination of selected team project and work item type.

The Reset action on the bottom of the dialog allows you to reset all settings to default or policy values, depending on whether a project policy is set for the team project or not.

Two additional controls for the management of project policies are available to project administrators. The checkbox Set as project policy located in the Server/Project group is used to mark a set of configurations as a project policy. The Save to Server button, located next to the Reset button, is used to put the policy in place by saving it on the TFS server. Check this separate blog post to learn more about project policies in TeamCompanion.

Controlling Settings per Work Item Types

A typical scenario we wanted to cover with our enhancements can be described like this: “A mail created from a Product Backlog Item and from a Task can be formatted in different ways, according to business needs for each particular work item type.”

For example, when you send an email containing a PBI, you want to emphasize its Effort, Business Value, Backlog Priority and Acceptance Criteria. This gives important information to someone dealing with PBIs. On the other hand, the same fields do not have any meaning for a task (they are even not used for task). For someone interested in a task, main information comes from fields Assigned To, Remaining Work and Description . Further more, the most important fields for a bug are its Severity, State, Effort and Steps to Reproduce. Some of these fields are shared with a task, others are not.

Let’s first analyze the two default configurations you get with the installation. The default one is named “All work item types” and is applied to all work item types which do not have their own configurations defined. This configuration can not be deleted. Additionally, we deliver a configuration for the work item type Bug with its own particularities. The difference between these two configurations is visible, for example, when creating a work item from an email. When creating a bug, the email body gets copied in the ReproSteps work item field. When creating any other work item except a bug, the email body gets copied in the Description work item field.

Now, let’s configure the Send Work Item per Email action to support the scenario described above for our 3 particular work item types: Task, Bug and Product Backlog Item.

For the work item type Task, we are going to use the configuration “All work item types”. This means that we are not going to add an extra configuration to handle this work item type. On the picture below, you can see that in this configuration, for the Send Work Item per Email action, the checkbox Use Work Item Html preview as Email body is checked.

Default configuration for 'All Work Item Types' and action 'Send Mail'

This means that when sending Tasks per email, you will send standard HTML previews for these work items.

Default HTML preview used when sending tasks per email

For both work item types Product Backlog Item and Bug, we are going to use their own configurations. In both cases, we are going to override the default HTML preview for the Send Work Item per Email action and create a HTML based mail body which will contain all important fields for these work item types, which we specified above in our scenario.

Let’s first customize the existing set for Bug. In the Work Item Type dropdown select Bug. Uncheck Use Work Item Html preview as Email body, check Use HTML markup in body and on the Send Mail tab, in the New e-mail body edit box, enter the following HTML snippet:

Custom configuration for 'Bug' and action 'Send Mail'

Here is the code used for the snippet to format an email containing a bug:

<head>
  <style>
    table {border: 0px; font-family: "Calibri"; cellpadding: 2; cellspacing: 5;}
    td {vertical-align: top;}
  </style>
</head>
<body>
  <table>
    <tr><td><b>Title:</b></td>                <td>{System.Title}</td></tr>
    <tr><td><b>Web Access:</b></td>           <td>{TeamCompanion.WorkItemUrl}</td></tr>
    <tr><td><b>Assigned To:</b></td>          <td>{System.AssignedTo}</td></tr>
    <tr><td><b>Created By:</b></td>           <td>{System.CreatedBy}</td></tr>
    <tr><td><b>State/Reason:</b></td>         <td>{System.State}/{System.Reason}</td></tr>
    <tr><td><b>Severity:</b></td>             <td>{Microsoft.VSTS.Common.Severity}</td></tr>
    <tr><td><b>Effort:</b></td>               <td>{Microsoft.VSTS.Scheduling.Effort}</td></tr>
    <tr><td><b>Steps To Reproduce:</b></td>   <td>{Microsoft.VSTS.TCM.ReproSteps}</td></tr>
    <tr><td><b>System:</b></td>               <td>{Microsoft.VSTS.TCM.SystemInfo}</td></tr>
  </table>
</body>

When sending Bugs per email you will get the following layout in the mail.

Custom HTML format used when sending bugs per email

Finally, let’s add a new configuration which will be used for the work item type Product Backlog Item. Click on the + button (Add New Work Item Type Configuration) next to the Work Item Type dropdown, and on the Available Work Item Types dialog, choose Product Backlog Item. Confirm your selection and you will get a new configuration in the dropdown managing the behavior of work item type Product Backlog Item. Now, let’s repeat the same steps used to format emails for bugs, this time using a HTML snippet which highlights the most important fields of a Product Backlog Item.

Custom configuration for 'Product Backlog Item' and action 'Send Mail'

Here is the code used for the snippet to format an email containing a product backlog item:

<head>
    <style>
        table {border: 0px;font-family: "Calibri";font-weight: normal;
        font-size: 10pt;cellpadding: 2;cellspacing: 5;width: 100%;}
        td {border-bottom: 1px solid #0094ff;vertical-align: top;}
        p {background-color: #0094ff; vertical-align: top;}
    </style>
</head>
<body>
    <table>
        <tr><td width="20%"><b>Title:</b></td><td>{System.Title}</td></tr>
        <tr><td><b>Web Access:</b></td><td>{TeamCompanion.WorkItemUrl}</td></tr>
    </table>
    <p>&#160;</p>
    <table>
        <tr>
            <td><b>State</b></td>
            <td>{System.State}</td>
            <td><b>Reason:</b></td>
            <td>{System.Reason}</td>
            <td><b>Changed By:</b></td>
            <td>{System.ChangedBy}</td>
        </tr>
        <tr>
            <td><b>Effort:</b></td>
            <td>{Microsoft.VSTS.Scheduling.Effort}</td>
            <td><b>Business Value:</b></td>
            <td>{Microsoft.VSTS.Common.BusinessValue}</td>
            <td><b>Backlog Priority:</b></td>
            <td>{Microsoft.VSTS.Common.BacklogPriority}</td>
        </tr>
    </table>
    <p>&#160;</p>
    <table>
        <tr><td><b>Description:</b></td></tr>
        <tr><td>{System.Description}</td></tr>
        <tr><td><b>Acceptance Criteria:</b></td></tr>
        <tr><td>{Microsoft.VSTS.Common.AcceptanceCriteria}</td></tr>
    </table>
</body>

When sending Product Backlog Items per email you will get the following layout in the mail, containing more HTML formatting:

Custom HTML format used when sending product backlog items per email

As you can see, we have accomplished the goal of our initial scenario: now we emphasize important content for each work item type in a different way, which enhances more productive collaboration in our team.

Saving, Removing and Resetting Configurations Locally

In case there is no project policy set on your team project, you can locally manage your own preferences regarding the conversion between Outlook and TFS objects. Once you close the Options dialog by clicking on the button OK, settings for your configurations are saved locally and are used when performing all corresponding actions.

If you wish to delete a particular configuration, select it in the Work Item Type dropdown and click on the x button (Remove Selected Work Item Type Configuration). All configurations except “All Work Item Types” can be removed.

If you wish to reset all configurations and all settings to default values you got when installing TeamCompanion, simply click on the Reset button on the bottom of the Project Settings tab. This will delete any kind of customizations you created for all configurations and leave you with two default configurations “All Work Item Types” and “Bug”. For example, if you added new configurations for other work item types, these will be removed. If you deleted the configuration for Bug, it will be restored. If you made any customizations to the “All Work Item Types” configuration, they will be lost.

In case a project policy is in place on your team project, project settings are automatically distributed to all team members. This means that, in case you are not a project administrator, neither you can have your own settings, nor you can manage project settings. Please read further about managing project policies

Note: Examples in this blog are based on the Brian Keller’s Visual Studio 2012 RTM ALM Virtual Machine, which has been upgraded to Office 2013, Visual Studio and TFS 2013 RC and expanded with TeamCompanion 5.2. RTM.

TeamCompanion 5.2 for Team Foundation Server 2013 released

As TeamCompanion traditionally sim-ships with new Team Foundation Server versions, the latest release from Microsoft was not an exception. We are proud to announce that our newest version 5.2 fully supports the Visual Studio 2013 and Team Foundation Server 2013 released on 13th November this month.

Together with features already released in v5.1 which supported Team Foundation Server 2013 Preview, TeamCompanion v5.2 brings you following features and improvements:

Support for TFS 2013

TeamCompanion rides together with you when upgrading to the newest TFS release. No matter if you are using TFS server or VS Online, your favorite client will be at your disposal.

Support for multiple work item views

Note: Contents of this topic entry were updated after the release of TeamCompanion 5.2 Update 1.

The definition of each work item type contains the view for the work item form. Built-in TFS clients (Visual Studio Team Explorer, Web Access) handle just the default view definition. TeamCompanion handles multiple work item type views, allowing you to define different views for different users, TFS or AD groups.

You can benefit from this feature in many ways. Generally speaking, each type of stakeholder on your project is interested in and uses different work item fields. By defining different views for different groups or individuals, you can adjust their insight in the work item database. In this way they can focus just on those work item fields they really need from their perspective.

The following pictures show the same work item of type Epic displayed using two different views. The top picture shows a simplified view comparing to the view shown on the bottom picture and it contains only a selection of work item fields.

Simplified view of the Epic work item form showing a selection of fields

View of the Epic work item form with all fields

Project administrators assign views to roles using a supplementary administrative tool (available as separate download for TFS 2012and TFS 2013). Role-based view mappings can be defined on three possible levels: per user, per TFS group or per AD group. 

The following picture shows how three different mappings can be defined. Julia uses the custom view named “Custom View”,  the TFS group Fabrikam Fiber Web Team uses the simplified version of this view named “Custom View Simplified”, while the AD group Users uses the third custom view named “Generic View”. In this example, Julia has full access to work item fields on a customized form, the team gets a simplified version of the same view, while other users get only the preview containing general purpose work item fields. Users that do not fall into any of the defined mappings always use the default work item view, the same used by default TFS clients.

Administrative tool for managing mappings between users and groups and work item type layouts

Changes in role-based view mappings are saved on the server as part of team project settings and are retrieved by TeamCompanion when Outlook starts or when you connect to a new team project.

Multiple work item views or layouts are defined within work item type definitions. The following picture shows the rough structure of a work item type definition containing the default layout and three custom layouts used in the above example.

Work Item Type Definition With Multiple Layouts

Support for project level management of TeamCompanion configuration options regarding conversion between Outlook and TFS objects

Previous TeamCompanion versions allowed you to define a single set of configuration options regarding conversion between Outlook and TFS objects. The same rules where then applied to all team projects you accessed using TeamCompanion.

In this version we have improved this feature and now we allow you to manage the same settings per team project, so that different team projects can use different settings. The Options dialog has been redesigned and it now contains a single tab named Project Settings, which contains all settings related to the conversion between Outlook and TFS objects (Send Work Item as Mail, Create WI from Mail, Create Task from a Work Item and v.v., Create Meeting Request, Create WI from RSS). 

Conversion rules are now configurable for each work item type. This means that, for example, a mail created from a Product Backlog Item and from a Task can be formatted in different ways, according to business needs for each particular work item type.

By default, you get two sets of settings. The default one is named “All work item types” and is applied to all work items that do not have their own settings defined (this set can not be deleted). Additionally, we deliver a set for the work item type Bug. For example, the difference between these sets is visible when sending work items as emails. When sending a bug per email, the email body contains the contents of the ReproSteps work item field. When sending any other work item except a bug, the email body contains the contents of the Description work item field.

Configuration options regarding conversion between Outlook and TFS objects per team project on the Project Settings  Tab in TeamCompanion's Options

TeamCompanion supports two distinct cases:

Case 1: There is no project policy set and each user can manage his preferences locally. This is the default case after installation.

Case 2: Project settings are put in place in form of a project policy saved on the server. Only project administrators can manage project policy settings and they must explicitly save all changes to the policy on the server. In this case, policy settings are automatically distributed to all users after they restart Outlook. If users previously defined any local settings, these will be overwritten with policy settings without warning. Users without administrative privileges can only preview policy settings.

Support for backlog query changes introduced in TFS 2013

TeamCompanion stays always up to date with changes which Microsoft constantly introduces in its project management tools. This time we have implemented the recent change in Web Access so that our product backlog list now contains committed PBIs as well.

Various fixes and improvements

Thank you for your feedback. We fixed various bugs (e.g. creating work items from mails which contain embedded pictures) and improved particular features (e.g. highlighting of search results).

Series of real-life project scenarios featuring TeamCompanion

In the past months, we have published a series of correlated blog entries about real-life project scenarios where we show how, with the help of TeamCompanion, you can handle different realistic situations you come across every day in your development process. Here is the summarized list of topics we wrote about:
 
1. TeamCompanion enables Scrum teams to resolve capacity and prioritization issues more efficiently
Describes how you can try out different offline capacity and prioritization scenarios before you finally pick the one that best suits your situation.
 
2. Effortless Transparency - keep up with work item changes in an elegant and efficient way
Describes the TeamCompanion's easy and efficient solution how to stay on top of all events and be able to find the information you need, keep up with the development and be instantly aware of any changes to work items.
 
3. Various views on your work item database: Smart Grouping combined with Excel reporting
Describes an example how to combine TeamCompanion’s grouping support in work item queries with default excel reporting capabilities based on work item queries.
 
4. Feedback Request/Response Workflow with TeamCompanion
Describes how TeamCompanion helps you understand and incorporate continuous feedback in your ALM workflow
 
5. Organize your schedule around TFS work items 
Describes how TeamCompanion treats work items as first class Outlook objects, allowing you to add Outlook style flags, reminders and appointments for work items.

We are sure these scenarios will help your entire team to use TeamCompanion even more efficiently!
If you have any other interesting scenario about how you are using TeamCompanion to solve your everyday tasks, we would like to hear about it as well. Please do not hesitate to contact us.