July 26, 2010 at 11:39How Microsoft DevDiv Uses TFS - Part 3 + Add-on
- Transfer
In previous posts, I talked about our processes. Today I am going to introduce you to the implementation of these processes in TFS.
The image below is a rough idea of how they look. Read this article to get a better understanding of processes.
We use work items to track the information below.
Please note the following:
Pay attention to the following points:
What to look for:
Next, we’ll talk about how the planning processes worked in Orcas.
I got a question from Michiel about this article. The question was: how is the relationship between work items set? For example, Scenario to Value Prop, Value Prop to Experience, Experience to Feature?
For Scenario's case for Value Prop, we used the ALLOWEDVALUES list. We added a Scenario field to the Value Prop work item and set ALLOWEDVALUES as the type of this field. ALLOWEDVALUES is bound to the GLOBALLIST type, which is a list of scripts.
For all other types of relationships, we used links from one work item to another. In this way, we created links between the Value Prop and Experience work items. Such relationships simply show links in a special section of the work item form. You may have noticed that the MSF work item templates by default contain the Links tab, but the work items that we discussed above contain a list of links on the same tab as the description. This approach is just a design issue. You can display lists of links where it is more convenient for you.
A logical question may arise: “How do you prevent the creation of links from Value Prop to Feature directly? How do you maintain the right hierarchy? ”
The answer is: through exception reporting. Several people view reports that display incorrect links and remove such links. Perhaps not the best solution, but that is exactly what we did.
The image below is a rough idea of how they look. Read this article to get a better understanding of processes.
We use work items to track the information below.
Value Proposition Work Item
Please note the following:
- Scripts (Scenarios) are implemented by adding a special script field in a work item of type Value Prop and setting the value ALLOWEDVALUES to the script list. Since the number of scenarios (also known as business goals) is limited by a rather small and fixed number, this approach seems appropriate.
- The relationship between Experience and Experience is controlled by referring to each other of these types of work items.
- The type of the work item of the Value Prop should contain several fields, and, first of all, the Description field, explaining why this value itself was described.
Work item Experience
Pay attention to the following points:
- The Experience work item is associated with the Value Prop parent.
- The Experience work item refers to children of the Function type.
Feature Work Item
What to look for:
- The Type type refers to the parent type of Experience.
- The Features type must contain many fields describing it. The Description field sets the summary of this element to facilitate the search.
- For a more detailed description, the user can go to the single-page specification of this functionality. This document is presented as an external link in a special field.
What's next...
Next, we’ll talk about how the planning processes worked in Orcas.
Addition
I got a question from Michiel about this article. The question was: how is the relationship between work items set? For example, Scenario to Value Prop, Value Prop to Experience, Experience to Feature?
For Scenario's case for Value Prop, we used the ALLOWEDVALUES list. We added a Scenario field to the Value Prop work item and set ALLOWEDVALUES as the type of this field. ALLOWEDVALUES is bound to the GLOBALLIST type, which is a list of scripts.
For all other types of relationships, we used links from one work item to another. In this way, we created links between the Value Prop and Experience work items. Such relationships simply show links in a special section of the work item form. You may have noticed that the MSF work item templates by default contain the Links tab, but the work items that we discussed above contain a list of links on the same tab as the description. This approach is just a design issue. You can display lists of links where it is more convenient for you.
A logical question may arise: “How do you prevent the creation of links from Value Prop to Feature directly? How do you maintain the right hierarchy? ”
The answer is: through exception reporting. Several people view reports that display incorrect links and remove such links. Perhaps not the best solution, but that is exactly what we did.