Using a Three Tier Work Item Hierarchy With TFS 2010

  • Article

This blog is to introduce you to one three-tier work item strategy we use at Microsoft for tracking requirements and tasks during iterative solution development. It comes in the form of a process template provided as a download in this post that you can upload to your TFS 2010 implementation. It is a small modification to the MSF Agile 5.0 process template that will allow you to better track User Stories through Features and Capabilities. I will provide further updates on this moving forward. In the meantime, please feel free to post comments or questions. It also includes a Change Request work item that is sorely missing from the out of the box process template, which is based on the Issue work item. In a later post, I will discuss methods to effectively incorporate the Change Request into the hierarchy.

Note: There are no warranties or support expressed or implied with the provided template, and it is to be used at your own risk. Please do not upload this template if you are not experienced with TFS 2010 process template management. Of course, you can always give MCS a call and we will be happy to scope a consulting engagement that will assist you in all things TFS 2010 (sorry about the shameless plug).

Structure of Process Template Change

The MSF Agile template has been slightly modified by adding a required Type field in the Planning section of the User Story work item. When you create a User Story, you must select the type as either a Feature or a Capability, as seen below:

image

Feature

So what is a Feature? A Feature:

  • Represents a business level requirement from a customer.
    • Singular documented need of what a particular product or service should be or do.
    • Statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user.
  • Sets of features are used as inputs into the analysis and design stages of development.
  • Features show what elements and functions represent the project vision and are candidates for establishing project scope.
  • A well written feature will have the following form:
    • System or component being requested
    • An Action the System or Component should perform
    • The outcome of the action
    • The recipient of the action

Some examples of a high-level Feature as specified in the User Story title would be:

  • Provide theming and skinning capabilities for customer website
  • Allow users to have options for how products are displayed
  • Provide SEO friendly URLs
  • Provide ability to support user profiles

You would further flesh out each of these Features in the Details tab of the User Story.

Capability

A Capability:

  • Represents system level capabilities, which capture and track what the product needs to do to solve the customer problem.
    • Functional
    • Quality of service
    • Safety
    • Security
    • Operational
    • Interface
  • Provides as much detail as possible to ensure a developer can implement the capability, and that a tester can test the capability.
  • For functional capabilities, a scenario, or flow of events, that lays out the steps of a procedure are important. For other capability types, make the description as measurable as possible.
  • KEY POINT: If a test cannot be written from it, then it isn’t descriptive enough

Capabilities provide the specific, system level implementation details for any given Feature. For example, for the “Provide SEO friendly URLs” Feature above, here are some Capabilities which provide the details required to implement this Feature:

  • Standardize URL Routing based on SEO rules
  • Ability to generate concise default URLs based on default rules
  • Ability to support developer environment by specifying host name
  • Document high-level approach

A Capability should always be associated with a Feature. You may find cases where it is difficult to distinguish between a Feature and a Capability, but if you always refer back to the guidance above, along with experience, you will eventually make better distinctions. This may not be intuitive at first, but the ability will come with time, and don’t get too worried if your User Stories aren’t as pure as you might expect.

Querying on Features and Capabilities

The Work Item Type field can be queried on, so you can have hierarchical queries that show Features with their corresponding Capabilities as follows:

clip_image004

Work Item Relationships

Features are parents to Capabilities, and Capabilities are children to Features. Always remember the hierarchical nature of this relationship as this can sometimes be confusing for someone just getting used to the Features/Capabilities paradigm. Below is a diagram demonstrating work item relationships in view of Features and Capabilities:

image

Notice that Features, since they are business requirements, are tested with UAT Test Cases, whereas Capabilities, since they are system-oriented, are tested with System Test Cases. The children of Capabilities will be the Tasks required to achieve the goals of each Capability. So please be careful to follow this relationship model as it is proven and is designed to provide for a robust but simple workflow that is consistent with the iterative software development.

Interest in levels of detail with respect to work item types will be determined by role. Below is a mapping of roles to the level of work item detail they normally are interested in:

  • Customer/Engagement Manager – Features
  • Project Manager/Leads – Capabilities
  • Developers – Tasks

Test Cases and Bugs each track quality and are of interest to everyone.

Stack Ranking

Stack ranking is very important to successful agile projects because stack ranking forces you to prioritize and deliver the highest value items first. You may find that items towards the bottom of your stack rank appeared to be high priority when first loaded into TFS, but once the ranking was done, found their way to the bottom based on project goals. Thus, don’t neglect this very important process.

  • Rank Features and Capabilities by stacking them in rank order (with 1 highest).
  • No two Features or Capabilities can have the same rank (very important!)
  • Start with Features, then move down to Capabilities
  • Each must be evaluated and hard decisions must be made to pick the most important items.

This process should be repeated multiple times in order to drive out true priority requirements, so don’t expect this to be final the first time.

Three Tier Hierarchy - MSF for Agile Software Development v5.0.zip