UPDATED: Agile project management with TeamCompanion – “Plan and Prioritize”




Plan and Prioritize is used for agile project management. Each team project has ”Plan and Prioritize” node and it is located within the “Work Items” node between “My Queries” and “Team Queries”.

It provides support for product backlog grooming and prioritization, sprint planning and balancing load within team and for day to day task tracking using burn down chart. Using drag-and-drop in the backlog view, Work Items can be prioritized. By dropping them on the iterations tree on the right, they are assigned to specific iteration.

Note: throughout this description we will mostly use the term “Iteration”. If you use Scrum, just read “Sprint” instead and everything will make more sense. For all practical purposes these two terms are synonyms.

Visual tools and statistics help in (product) backlog grooming or sprint planning. In the iteration plan, Work Items can be assigned to a particular team member, area or activity. They can also be moved out of the iteration by dropping them on iteration list – to another iteration or back to the product backlog. Capacity settings for the iteration can be configured in the capacity pane and iteration’s progress can be tracked in the burn down pane.

Settings defined per iteration are mostly specific for one and only team, but in some cases those settings are shared among all teams (e.g. team member interruptions).

Filters on both backlog plan and iteration plan can be used to specify which items will be seen. You can filter by team member, Area Path, Work Item Type, discipline and by status.

When making any changes it is important to note that they need to be explicitly saved (via the ribbon button) and they can be discarded via the Undo ribbon button. Prioritization is also possible in offline mode and all changes can be undone via the ribbon button. If changes are not saved or TFS connection is not present, they are automatically locally saved when Outlook is closed. Once connection with TFS is established once again, all changes can be saved on the server via the Save ribbon button.

Plan and Prioritize is best for projects with Scrum methodology, but it is also an excellent tool for projects that are based on other methodologies. Out of the box three process templates are supported: MSF Agile 5.0, MSF for CMMI 5.0 and MS VS Scrum 1.0, but as you can see at the end of this document it is easy to configure the tool so that it can be used with any process template.




Starting from TeamCompanion v4.2 all work done using our “Plan and Prioritize” feature is done in scope of one team. By default, if on some TFS project there is no teams defined, TeamCompanion will create a default team to which will be assigned default iteration, default scope and default member.

In all other cases, when “Plan and Prioritize” is selected, ribbon will be filled with a list of available teams and last selected team will become active again.

Using ribbon, you can always easily switch between teams or iterations that are part of some team.


“Manage Teams” ribbon action is used to manage teams. Using this dialog, authorized user can create, delete or edit teams. Project collection administrators and project administrators have full rights for teams management and only they can create a new team. While managing some team, project collection and project administrators can promote some team member to a team administrator. Team administrators have full rights to edit or delete “assigned” team.

In order to create a team, user needs to provide following information defining the filter returning only work items belonging to that particular team:

  • Team Scope – only work items in this/these Area(s) will be visible as part of the “Plan and Prioritize” queries.
  • Team Members – only work items assigned to team members will be returned by query.
  • Team Iterations – select iterations this team is interested in. Usually you will here select the current iteration, a couple of previous iterations (to be able to follow the velocity) and next few iterations to facilitate planning.Additionally, here you will choose one iteration used for this team’s Backlog.

Let’s take a closer look at a “Manage Teams” dialog:


First tab is primary used to define team scope (areas), but it can be used to define team administrators as well.

By setting team scopes, user will filter only a subset of available scopes that covers particular team. Default Scope will be assigned as a work item scope when some work item is assigned to a team using drag and drop action inside the “Plan and Prioritize” tool.

Team Administrators quick picker allows you to alter a list of team administrators.


Second tab is used to manage team members. Using this tab they can be added, removed or a discipline can be assigned to them (in order to facilitate management by disciplines where tasks are assigned to a discipline, instead of the management by particular team members). This tab is also used to define team administrators.


On the third tab, user can define backlog and team iterations. At least one backlog and team iteration must be selected. There may be multiple backlog iterations – work items from all of them appear in the team Backlog. The Default Backlog iteration will be assigned as a work item iteration when some work items is assigned to a team using drag and drop action inside the “Plan and Prioritize” tool.

Team Iterations represents a set of iterations on which one team works. All iterations defined in this section will be visible on ribbon and user will be able to switch between them. Each time user selects some iteration, work items will be filtered and will return only those that are part of the selected iteration.




Product Backlog plan is activated by clicking on the Backlog plan button on the Plan and Prioritize ribbon tab.


Items in the Product Backlog grid are called Product Backlog Items (PBI). If you use MS VS Scrum 1.0 this is the name of the work item type as well; for other process templates, work items of appropriate types appear here. The following image highlights some key features provided by the Product Backlog plan view.



  • Filters

    Several filters can be combined for the Work Items in the grid. You can filter by Area Path, Assigned To, Work Item Type, Discipline and you can also filter out non-active Work Items.

  • Full text filter

    Typing into the search box uses full text filter over all Work Items in the grid (and all fields of those work items, not just Description or Title).

  • Backlog statistics

    There are several important statistics for the product backlog visible above the grid. They are adjusted automatically when Work Items are dropped to a iteration.

  • Iteration statistics

    Load is drawn for iteration on the iteration tree list. This visual guidance helps when planning iteration to prevent capacity overflow.

  • Right hand tree list

    For quick iteration, area, team, team member or discipline assignment, tree list is visible on the right.

  • First class grid control with Work Item actions.

    The following image shows an example context menu for a grid item. All these actions are available for all PBIs. As you can see from the screenshot, it is easy to add child work items to a PBI or execute different other actions for one PBI or for selected group of PBIs. If you want to execute an action on all grid entries, just press Ctrl+A to select all items and then execute the action.

Usage scenario – backlog grooming

It is easy to change priority of each product backlog item (PBI) simply by using drag and drop. The following image shows an example of prioritizing user story. Thick black line denotes the new position for the user story after prioritization.

After changing the order, all Work Items that have changed their position will be italicized with gray background. Remember, all changes are first done locally only. Click on the Save ribbon button to apply changes or click on the Undo ribbon button to discard them and start anew.

Offline editing

All changes made by drag and drop on the PnP are saved locally first. If you are not satisfied with changes, you can always discard them by clicking on the Undo ribbon button. PBI order in the grid, Iteration changes, Assigned To changes, Area changes and Activity changes are all saved locally and they can be performed when running offline.

To save those changes on the TFS server, use the Save ribbon button.

Statistics: why do they matter and what do they mean

The following image shows an example of backlog plan statistics.



  • Scheduled User Stories

    Formula for Scheduled User Stories is [%]. This number represents percentage of all user stories that have been assigned to any iteration.

  • Scheduled effort

    Formula for scheduled effort is [%]. This number represents percentage of all remaining work for Work Items that are planned i.e. not in the Product Backlog.

  • User Stories done

    Indicates how many user stories are done.

  • Story points

    Sums story points for User Stories in the Product Backlog.

Usage scenario: Sprint planning meeting

Once the Backlog is groomed, we are ready to begin sprint planning. For each PBI, tasks are created (right mouse click and choose Add child Work Item, Task)  that represent development effort. The following image represents product backlog before decomposing the PBIs:

Once PBIs have been decomposed into tasks, situation has changed and the statistics are updated. To plan those Work Items, during the sprint planning meeting the team can simply drag and drop selected Work Items onto the designated iteration (in this example Iteration 3). The statistics for the iteration are immediately updated.


The following image shows the backlog after Work Items have been planned for the Iteration 3:


Note: backlog statistics are always calculated in story points using the following formula:
<sum of all active WIs assigned to iteration> of <Iteration capacity> - <sum of all WIs in done state assigned to iteration>.
If iteration capacity is not defined, only the sum of all active WIs assigned to each iteration will be displayed.


The following image shows all available filters:


When filter is activated, appropriate icon is highlighted. The following image illustrates the difference.


Various filtering options available through buttons above the grid help manipulate PBIs. You can filter by iterations (makes sense even if you are working in the product Backlog since (union of the) contents of multiple iterations may be considered the Product Backlog), by assignment (team members), area path, discipline, work item type and state. Full-text search as filter option is also provided via the search box to the right of filters.

You can remove all filters by clicking on the rightmost icon with small red x in the lower right corner. Filters are persisted through Outlook sessions.


  • Iteration Path filter

    By clicking on the first icon you can filter by iteration path. There is no limit to the number of backlog iterations. For example, product development can be divided in several release cycles where every cycle has several sprints. Each cycle can have its own backlog and union of all backlog iterations can be considered to be the Product Backlog. Backlog iterations and selected iterations can be set in the Configuration dialog.

    Note: There is always at least one iteration selected in the Iterations filter.

  • Area Path filter

    You can filter by multiple Area Paths by checking different Areas. By clicking on the node that has children, all children of that node are checked or unchecked, depending on the parent. If you wish to select individual nodes, simply check their check buttons. If no Area is checked, this filter is ignored. Area Path entries, that are visible in the filter list, are configured in the configuration dialog.

    When any checkbox is checked, the Area Path filter icon appears highlighted.

  • Assigned To filter

    This filter filters by Assigned To Work Item field. If no Team Member is selected, this filter is ignored.

    Visible Team Members in the filter are configured in the configuration dialog.

  • Work Item Type filter

    This filter filters by Work Item type. If no type is selected, this filter is ignored.

  • Discipline filter
  • This filter filters by Discipline (Activity). If no discipline is selected, this filter is ignored.

  • Other filter

    This filter filters by State. If nothing is checked, this filter is ignored.

    Which Work item states are considered Active (and which are considered Done which is complement of Active) in the filter is configured in the configuration dialog.

There is also full text filter which is activated by typing into the box to the right of the filters mentioned above. The following image illustrates usage of the full text filter:




Iteration plan can be activated by clicking on the ribbon buttons.



Usage scenario: Sprint planning meeting (continued)

After the rough iteration plan has been set, you must define the capacity. Select the desired sprint plan in the ribbon tab. Capacity is defined in two phases:

  1. Sprint start and end dates are set to define timeframe for the sprint
  2. Define any individual or team interruptions


    1. Individual interruptions allow you to account for vacations, sick days or any other day when particular team member will be absent.
    2. Team interruptions allow you to account for day-long events for the entire team, such as public holidays or any particular whole team activities.
  1. Define individual capacity


    1. Specify daily work load for certain individuals. This accounts for team members who have other obligations and are not working full time on this project.


All changes on this pane should be saved via the Save button on the lower right. Please note that the Save ribbon button will not save these settings. If you are unhappy with your changes, you can click undo to reset them.

Now assign tasks to team members until you have solid plan. To do that, simply drag and drop Work Items on the team members list in the lower right pane or drag and drop on the chart on the Team pane. Colors will help you visualize the workload for each individual team member to prevent overload.

All changes are not saved immediately, you must click on the Save ribbon button or you can discard changes by clicking on the Undo ribbon button. All changes are firstly done locally and only if you are happy you can save them. Otherwise, undo and try something else. This kind of what-if analysis is especially useful for planning, where you might like to work out different options before you settle for the optimal one.

Usage scenario: Daily standup

Once you start sprinting, TeamCompanion lets you constantly know what is going on by providing real time burndown chart (based on historical information from transactional Work Item data, not the OLAP cube).

The following image shows an example burndown chart:

Team pane

Team pane displays chart with workload and capacity for each team member. The name of the Team members displayed in this chart are defined in the Configuration dialog. Capacity is always defined as remaining capacity as of this day, not an absolute capacity for the iteration duration. This is an excellent visual tool that allows you to see if team member is overloaded for the rest of iteration. If team member falls behind in his schedule, workload will surpass remaining capacity.

If there are Work Items in iteration which are not assigned to any team member, they will not appear in the chart if the “Show team members only” checkbox Is checked. If you wish to see how many hours of remaining work are assigned to non-team members, uncheck the checkbox. Default remaining capacity for non-team members is calculated as if the person were a regular team member with no personal interruptions.

To visualize the workload of a few Work Items only, check the “Show for selection only” checkbox and the graph will be adjusted whenever you change selection. Darker shades of blue and red will match remaining work for all selected Work Items while the lighter shades will show total remaining work. It is easy to see part taken by the selection.

When filters are enabled, grid displays partial results. Team chart will use dual colors to display remaining work for filtered items (darker shades) and for all items (lighter shades).

Capacity pane

Iteration capacity is defined on the Capacity pane. Start date, end date and work hours per day should be defined for the iteration. Default values for these fields when you first start editing iteration are:

  • Start date = today
  • End date = two weeks from now
  • Work hours per day= 8
  • Story points = 0

When you define iteration capacity, it is defined for one (currently selected) team only. Almost all here defined settings are valid for currently selected team only. However there are few exceptions, e.g. team member interruptions which are shared among all teams.

Iteration duration is calculated as the number of working days between and including start and end dates minus team interruptions. Working days are defined in Outlook. You can change them by going to the File ribbon tab, click on Options, select Calendar on the left and edit Work week checkboxes (example on the image below).

Remaining capacity is the total capacity for this iteration from today until the end of the iteration. It is calculated as the sum of individual capacities for team members in this iteration. Weekends, personal and team interruptions, and individual capacities are all accounted for.

Iteration capacity in story points is used on backlog plan as an alternative way for display iteration current status

The following image displays upper part of the Capacity pane with an example configuration.


To add individual interruption, click on the Add new button to the right of the first grid. You can write short description (such as “Vacation”) for the interruption. Team member, start and end date are all necessary fields. The Duration column displays total length of the interruption excluding weekends. The Remaining column displays number of remaining days for this interruption excluding team interruptions.

To add team interruption, click on the Add new button to the right of the middle grid. You can write short description of the interruption and you must select correct date.

To define special capacity for team member who is partially available for the current sprint, click on the Add new button to the right of the bottom grid. You must select the team member and write number of working hours for her.

  • The Days column displays how many days will this team member work in the sprint, excluding personal interruptions and team interruptions.
  • The Capacity column displays the total remaining work hours for the team member.
  • The Assigned column displays sum of remaining work for Work Items that are assigned to the team member in the sprint.
  • The Utilized column displays number of utilized hours for the team member. This number is equal to the Capacity column value if the team member is overloaded, or is equal to the Assigned column value if the team member has free time.
  • The Over column displays number of extra hours assigned to the team member over his capacity.
  • The Under column displays number of extra hours that can be assigned to the team member.

The following image displays an example capacity configuration.

All changes on the capacity pane are saved locally. They must be saved via the Save button on the pane, not via the Save ribbon button. If some data was accidentally modified or deleted, changes can be undone via the Undo button.

If you do not have sufficient rights to edit the Capacity pane, it will appear as read only and you will see a warning.

Team Project and Project collection administrators can edit capacity pane. If you wish to add editing rights to another TFS security group, you can do it on the Security tab on the Process Template part of the Configuration dialog.

Burndown Pane

The Burndown pane contains the burn down chart for the current sprint. You can track sprint progress by comparing the Remaining effort line (green line) with the Ideal burndown line. As long as the Remaining effort is under the Ideal burndown line, sprint is on schedule. If there were impediments in the sprint or if the estimation for remaining effort were wrong, the Remaining effort line will slip over the Ideal burndown line.

Daily number of completed tasks are displayed as orange columns. Number of remaining tasks is displayed as orange line.

X axis represents sprint days starting from day 0 (day before the first day) until the last day of the sprint. Day 0 represents starting point when the sprint actually begun since there may already be some completed work on the first day and the remaining work.

Configuration dialog

Agile project management features work with any TFS process template, but three templates are supported out of the box. They are MSF Agile 5.0. MSF CMMI 5.0 and MS VS Scrum 1.0. These three templates will be automatically recognized and if your team project is based on any one of them, you can start using the tools straight away. For other templates you will firstly have to configure the tool. Don’t worry, configuring it is easy. Just press Configure button in the ribbon.

In the first tab of the process template configuration dialog, various settings are defined that make it possible for TeamCompanion to show the Backlog, support changing the order of PBIs using drag and drop, provide statistics etc.


The following image shows configuration for Microsoft VS Scrum 1.0 process template.


In the second tab, the Sprint work item is chosen (currently used in MS VS Scrum 1.0 template only).


In the third tab, Active and Done states for the PBI work item type are defined. Remember that the PBI work item type itself is defined in the first tab.


In the fourth tab you can define the columns for the backlog or for the iteration grid.


By default only project collection and project administrators can edit these settings. Since this is obviously too restrictive, in the fifth tab they can give permission to edit the process template configuration to any TFS security group defined for the project.



Once you make your changes, they are saved on the server and everyone else connected to the project will see changes when they refresh Plan and Prioritize.

This was an overview of the agile project management feature in TeamCompanion named “Plan and Prioritize”.

What others are saying.

No comments posted yet.

What do you have to say?

Email (never displayed)
(will show your gravatar)
Please add 8 and 3 and type the answer here: