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).
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:
So what is a Feature? A Feature:
Some examples of a high-level Feature as specified in the User Story title would be:
You would further flesh out each of these Features in the Details tab of the User Story.
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:
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.
The Work Item Type field can be queried on, so you can have hierarchical queries that show Features with their corresponding Capabilities as follows:
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:
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:
Test Cases and Bugs each track quality and are of interest to everyone.
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.
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.