Team Foundation Server with Agile
Microsoft’s Team Foundation Server (TFS) is very popular and used on many agile projects. Here are a few tips and tricks to make your agile experience with TFS considerably more productive. To begin with I recommend you consider the scrum (x) template as a starter. It is a pared down version of their standard template which has everything including the kitchen sink thrown in. Novices in particular will get less confused with the scrum (x) template since it is simpler. The following are seven tips to make your use of TFS more effective.
1. Add a field called “thematic releases” to your work items. Have the product owner populate this field. The thematic release field holds a term that is understandable by the user community that expresses the business or functional goal of the release. The product owner uses the thematic release field as a “parking lot” where he or she can place the user stories that they want to be considered for the next release. The iteration field will still hold the development sprint identifier and group all the work that the development team has agreed to do within a sprint. The Scrum Master/Facilitator sets the iteration field in TFS based on the items the development team agrees to accept during the iteration planning session.
2. Add a check box to work items called “Global Requirement”. Global item user stories are the receptacle for general standards or requirements. They usually exist at a product level. These are mined for applicability at the beginning of a thematic release identification. They are copied to create a user story work item in a thematic release by the product owner and/or BSA responsible for the product area and customized to show specifically how it applies to this release. Standards like software architectural, system architectural, technical architectural diagrams, work flows and data models are linked with a hyperlink type from products to the latest copy of each of these items. This is because the latest standard always applies at the product concept level. For the user story when it gets into a thematic release the requirement or standard is attached, which freezes the document.
3. All epics or user stories (always link from the highest level appropriate its easier) that refer to a wireframe[1] will have the hyperlink to the wireframe included as a related link. An epic or a user story can point to more than one wireframe and more than one user stories or epics can point to a single wireframe.
4. Add a new work item called product to be used as container for epics. Products are things which you sell to customers or buy from vendors. Products can be composed of other products and/or epics. Products give you the highest level view of the system from the customer’s or user’s perspective. They establish the scope of the solution. They do not have thematic releases associated with them, that happens at the user story level. For the most part, the product owner defines the product work items and associates epics with it. A product work item contains valuable requirement definition information which will be part of any resulting or child object’s requirement. A user story does not exist in isolation. It inherits meaning and requirement from predecessor items like products and epics.
5. Add a new work item called epic to be used as a container for user stories. Epics are major areas of functionality that are not a product in themselves, but encompass multiple user stories. Epics for the most part do not breakdown into other epics. They are decomposed into user stories. Epics provide an easy mechanism to understand what a product actually does and help identify future considerations. Epics do not have thematic releases.
6. Of course use a user story as it was intended. Here’s a bit of a process snippet:
A. I like to start with a product(s) definition backed by some appropriate standards (Yes, I actual talk to Enterprise Architects and in fact, off and on, function in that capacity. I don’t view them as enemies.)
B. I follow this with a high level breakdown of major function that is at an epic level. Epics usually decompose into 5 to 10 user stories, but can contain as few as 2. Epics can be one of the basis of segregating work when managing in a scrum of scrums philosophy.
C. It is at this point I usually hold a release planning session.
D. At this point I create user stories. Data models begin to form no later than this point from data elements identified at higher levels. I actually don’t waste time creating conceptual models[2] first, but begin to create tables and flesh them out as the user stories evolve.
E. It’s at this point I usually hold an iteration planning session.
F. I generally develop the acceptance criteria after any wireframing that the user story requires is mostly completed.
G. I develop the test cases from the acceptance criteria and the associated completed wireframes.
H. The developers usually begin their serious coding effort at this point.
I. I would like to see test scripts delivered to the developers up front as well, but generally I am building them after the developer begins to work on a user story.
J. As a user story is completed and turned over to test I begin with the user documentation.
K. I always save a final iteration or sprint (never more than 2 weeks) as a system hardening sprint where no code is developed just system testing and bug fixing occurs.
7. Creating a tree view query is a helpful tool for you to use to view/mine all the information relating to a product/epic/user story segment in TFS. I recommend several different customizations; one that shows you all work in a thematic release, one the shows you all work in an individual sprint or iteration and one that shows you all the work assigned to you in an individual sprint or iteration.
[1] I use usually use Balsamiq Mockups for wireframing (oops a product recommendation just slipped in).
[2] I am sorry for all you hard core believers of conceptual modeling, but it really is an old concept that doesn’t work well in agile development you can get the same result or better working directly with most good RDBMS design tools that dynamically create and execute the Data Definition Language directly.