By: Dave Smith and Brian Lucas
Since I posted the first set of tips about TFS usage for agile, I received so many requests for additional information that my friend and colleague Dave and I happily collaborated on a list of tips and practices to not only make your use of TFS more effective, but also to make your life a whole lot easier. Let us know what you think and what your good tips are! -Brian
Explanation of terms and practices in Microsoft’s Team Foundation Server
- Use TFS as the repository for all information about your agile effort.
- TFS is easy to use, stable and powerful environment that enables you to relate and communicate ideas and statuses to a team fluidly.
- Keep everything from business plans and justifications to marketing strategies to product definitions to user stories and of course code.
- Keeping your user stories on 3X5 cards and throwing them away afterwards is a waste.
- You will find that having an incontrovertible source for why you did something is very helpful in preventing its repetition.
- Over time you will find that you can mine this information for reusable items both at the logical and physical levels.
- An important part of optimizing TFS is using the very powerful customization features TFS has for work flow, screen and querying. Take advantage of them and make the process your own when it is of benefit.
- Prepare TFS ahead of time:
- Set up your individual process by customizing the work flow where necessary.
- Get your TFS administrator to add the customization elements.
- Put together team queries that provide a customized look at the data in a common format that you want members of the development team to use.
- Provide TFS training for all team members including the Product Owner.
- Draft status
- Use a status of “draft” to be available for each work item so team members know when it is still a work-in-progress.
- Thematic release
- Is the cohesive activity that represents a customer understood product value that will take place in a discrete period of time; usually 6 weeks.
- Releases can still be tracked and referred to internally by a numeric expression like release 1.2.1, but the thematic release is a term that must be known and used by the entire development team; especially in any dealings with an external customer.
- A new field must be added to work item forms called thematic release.
- Thematic releases are parking lots for the Product Owner to place User Stories considered for a particular release.
- The Product Owner defines the thematic release.
- A thematic release uses language that is understandable by user community.
- It expresses the business or functional goal for the release.
- Also known as a sprint.
- Iterations contain the actual work that the development team has agreed to do within a specific period of time usually 2 weeks.
- The Scrum Master/Facilitator sets the specific user stories the development team agrees to develop in the iteration based on the iteration planning session.
- Products and epics
- Must be added as new work items in TFS.
- They are used as containers or groupings for user stories.
- They contain valuable requirement definition information which is part of the resulting or child object’s requirement.
- They address the “User Story overload complexity issue” haunting large agile projects.
- When looking at a User Story it is important to follow the chain back to the epic that spawned it and the product(s) to understand the full context that the User Story is being couched in and follow any additional requirements that exist at a higher level.
- Tree-view Query
- A tree-view query should be used to list the nested objects that are contained in a products/epics/user stories structure see below.
- Individual development team members should customize this into several queries:
- One shows all work in a thematic release,
- One shows all work in an individual sprint or iteration
- One shows you all the work assigned to you in an individual sprint or iteration.
- Products are things which you sell to customers or buy from vendors.
- They can be composed of other products and/or epics.
- They give you the highest level view of the system from the customer’s perspective.
- They establish the scope of the solution.
- They do not have thematic releases associated with them because they are evolving.
- The Product Owner defines the product work items and associates epics with it.
- Standards like software architectural, system architectural, technical architectural diagrams, work flows and data model are linked from products in order to always point to the latest version of these documents.
- Epics are major areas of functionality that are not a product in themselves.
- They encompass multiple user stories.
- Epics do not breakdown into other epics. They are decomposed into user stories.
- They provide an easy mechanism to understand what a product actually does and helps identify future considerations.
- Epics do not have thematic releases.
- User Stories
- It is important that user stories represent the same level of development as much as possible so that they are not confusing to the development team.
- User stories should not breakdown into other user stories.
- User stories also usually represent an aggregate level of work and don’t refer to adding a field to a report unless it is an existing report and only needs one field.
- While there are natural differences that can and will occur in user stories as different people create them, they should be as close as possible to the same scope of work.
- Ultimately the Product Owner needs to be the final arbitrator of user stories since all the work is being done for him.
- Release Planning
- Structure in meetings with a clear purpose declared for the meetings is necessary.
- Don’t skip release planning or gloss over the meeting – be prepared.
- Don’t hesitate to redefine the thematic release if it becomes clear in the release planning that there are unknowns or that the anticipated effort was underestimated by the Product Owner.
- Actions to improve planning sessions, reviews and retrospectives.
- Use a projector capable of displaying the application in the recommended resolution.
- Demo the application in the supported environment/browser.
- TFS should be shown on another projector and drive the session in order to:
- walk down the list of user stories in the iteration and see the actual verbiage
- update TFS state (Passed, Passed with Noted exceptions, Failed with failure reason)
- Product Owner feedback
- Demo to the Product Owner with single point of contact from the Test Team as soon as there is an appreciable demonstrable function.
- Demo frequency should be every other day and not last more than 10-20 minutes.
- The tester who is demoing will make any necessary changes in TFS (mostly in the acceptance criteria area or adds appropriate comments about what was liked or disliked) or adds comments or annotations to the wireframe if necessary.
- If there were design issues, then UI Designers can get involved and update the wireframes. This puts the Product Owner in an excellent position to see the EVOLVING solution and be more PROACTIVE in guiding its birth.
- This does not mean having requirements change introduced into a sprint. What it represents is the Product Owner’s ability to monitor and appreciate the results in as real time of a scenario as possible. If something is not working the way the product Owner anticipated; new requirements can be added to the next (or other future sprint).
- If a Work Item is not as anticipated the Product Owner can also stop the work in deference to a future sprint.
- Logging during retrospective
- If a developer feels that an issue was not a defect it usually isn’t logged. This is always a problem and it usually slips between the cracks.
- You may choose not to fix an issue based on cost or time or the development team might not be able to technically address it, but they still need to be logged in TFS as bugs.
- For the release retrospective, the Product Owner’s comments on the release (along with any other comments that represent the group consensus) should be recorded in TFS .
- Roles and responsibilities should be clearly defined along with the terms, concepts and tools usage.
- Anyone who has an idea can enter it into TFS.
- This captures good ideas on-the-fly and allows a Product Owner to be enriched by the creativity of the entire team.
- The Product Owner expands on these and assigns a Stack Rank
- Stories the Product Owner feels are not substantive ideas, he sets to a Stack Rank of 100 or discards them entirely.
- 1st version of User Story
- The Product Owner documents the first version of the User Story.
- Ensures intent is captured independent of any prejudices or preexisting systems.
- Gives the owner the opportunity to flavor the entire effort.
- Drives the development early on from a business perspective not an IS/IT one.
- BSA Refinement
- Once the idea has been entered and deemed worthy of effort a BSA and/or SME will work with the Product Owner and User Story definer to initially clean up the User Story and park it in an appropriate Product/Epic/User Story segment.
- Part and parcel to this is the addition of extra elements of specification as appropriate. These include data definitions, models, architectures and business rules.
- Comments from various parties can be documented in TFS under the User Story in the same manner as comments written on the back of a 3X5 card. These can take the form of a running stream of comments with the originator identified. Time /dates are not important since the comments are made for clarity.
- Flesh out User Story
- A User Story is identified as a part of a thematic release by the Product Owner.
- BSA works with the Product Owner and SME (if assigned) to flesh out the story.
- Wire Framing
- BSA and GUI person wire frame an interface interactively with the Product Owner.
- When the Wire Framer is comfortable that the User Story is ready for public consumption they will attach it to the User Story via a hyperlink.
- User stories that refer to a Wireframe will have the hyperlink to the Wireframe included as a related link in the User Story
- A User Story can point to more than one Wireframe and a Wireframe can be pointed to by more than one User Story.
- Global user stories
- Contain general standards or requirements.
- They are hyperlinked to from the product level.
- They are mined for applicability at the beginning of each release and are copied into a User Story work item for a thematic release by the Product Owner and/or BSA responsible for the product area and customized to show specifically how it specifically applies to the release.
 “Those who don’t know history are destined to repeat it.” – Edmund Burke
 Don’t become a “white elephant” though.
 The TFS administrator will have to add this.
 Whenever possible use TFS dynamically during work or meetings. Don’t take notes and then later do the work in TFS, that’s inefficient and error prone. I assure you if you use TFS daily you will become more than proficient in it to capture and modify artifacts on the fly without slowing down a live collaborative event.
 I receive a lot of emails and get a lot of questions about how to manage the complexity and volume of user stories in TFS. This is particularly true in products that have a large scope or when people are managing a scrum of scrums or in distributed (non-co-located) agile teams.
 I have deliberately not included estimation techniques here, but will cover them in a future post.
 The tester takes daily builds and tests them out in what is a unit test fashion to help the developers. The test team is in the best position to support this kind of demo activity to the Product Owner.
 As another work item called the Release Retrospective. Release Retrospectives are very special events. They represent the BIGGER picture unlike sprint retrospective which tend to focus on tactical issues. Recording this information in the common repository of TFS and directly associating it with the release will give you a perspective over time that will help guide strategic direction. If you don’t do this you can never be sure you won’t repeat your mistakes. This will eliminate the need to separately publish the results of reviews and retrospectives to the team since they will be in TFS.
 I will post something on general role definitions in a later post.
 Work item delete capability should be granted to a responsible Product Owner
 This is a concept that addresses one of the persistent stumbling blocks in agile projects; where to store and how to apply global requirements. By keeping with the TFS concept we have a single, stable, safe and easy to use source for all these. The dynamic global area allows documents to change over time, while the instantiation as a User Story in iteration allows for specific common sense application and stability for the development team. It is the best of both worlds.