Using Microsoft’s Team Foundation Server to Your Agile Best

Posted on July 30, 2012 by Brian Lucas

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

  1. Use TFS as the repository for all information about your agile effort.
    1. TFS is easy to use, stable and powerful environment that enables you to relate and communicate ideas and statuses to a team fluidly.
    2. Keep everything from business plans and justifications to marketing strategies to product definitions to user stories and of course code.
    3. Keeping your user stories on 3X5 cards and throwing them away afterwards is a waste.
    4. You will find that having an incontrovertible source for why you did something is very helpful in preventing its repetition[1].
    5. Over time you will find that you can mine this information for reusable items both at the logical and physical levels.
    6. 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[2].
    7. Prepare TFS ahead of time:
      1. Set up your individual process by customizing the work flow where necessary.
      2. Get your TFS administrator to add the customization elements.
      3. 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.
      4. Provide TFS training for all team members including the Product Owner.
  2. Draft status
    1. Use a status of “draft”[3] to be available for each work item so team members know when it is still a work-in-progress.
  3. Thematic release
    1. Is the cohesive activity that represents a customer understood product value that will take place in a discrete period of time; usually 6 weeks.
    2. 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.
    3. A new field must be added to work item forms called thematic release.
    4. Thematic releases are parking lots for the Product Owner to place User Stories considered for a particular release.
    5. The Product Owner defines the thematic release.
    6. A thematic release uses language that is understandable by user community.
    7. It expresses the business or functional goal for the release.
  4. Iteration
    1. Also known as a sprint.
    2. Iterations contain the actual work that the development team has agreed to do within a specific period of time usually 2 weeks.
    3. The Scrum Master/Facilitator sets[4] the specific user stories the development team agrees to develop in the iteration based on the iteration planning session.
  5. Products and epics
    1. Must be added as new work items in TFS.
    2. They are used as containers or groupings for user stories.
    3. They contain valuable requirement definition information which is part of the resulting or child object’s requirement.
    4. They address the “User Story overload complexity issue[5]” haunting large agile projects.
    5. 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.
  6. Tree-view Query
    1. A tree-view query should be used to list the nested objects that are contained in a products/epics/user stories structure see below.
    3. Individual development team members should customize this into several queries:
      1. One shows all work in a thematic release,
      2. One shows all work in an individual sprint or iteration
      3. One shows you all the work assigned to you in an individual sprint or iteration.
  7. Products
    1. Products are things which you sell to customers or buy from vendors.
    2. They can be composed of other products and/or epics.
    3. They give you the highest level view of the system from the customer’s perspective.
    4. They establish the scope of the solution.
    5. They do not have thematic releases associated with them because they are evolving.
    6. The Product Owner defines the product work items and associates epics with it.
    7. 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.
  8. Epics[6]
    1. Epics are major areas of functionality that are not a product in themselves.
    2. They encompass multiple user stories.
    3. Epics do not breakdown into other epics.  They are decomposed into user stories.
    4. They provide an easy mechanism to understand what a product actually does and helps identify future considerations.
    5. Epics do not have thematic releases.
  9. User Stories
    1. 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.
    2. User stories should not breakdown into other user stories.
    3. 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.
    4. 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.
    5. Ultimately the Product Owner needs to be the final arbitrator of user stories since all the work is being done for him.

Process

  1. Release Planning
    1. Structure in meetings with a clear purpose declared for the meetings is necessary.
    2. Don’t skip release planning or gloss over the meeting – be prepared.
    3. 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[7].
  2. Actions to improve planning sessions, reviews and retrospectives.  
    1. Use a projector capable of displaying the application in the recommended resolution.
    2. Demo the application in the supported environment/browser.
    3. TFS should be shown on another projector and drive the session in order to:
      1. walk down the list of user stories in the iteration and see the actual verbiage
      2. update TFS state (Passed, Passed with Noted exceptions, Failed with failure reason)
  3. Product Owner feedback
    1. Demo to the Product Owner with single point of contact from the Test Team[8]  as soon as there is an appreciable demonstrable function.
    2. Demo frequency should be every other day and not last more than 10-20 minutes.
    3. 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.
    4. 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.
    5. 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).
    6. If a Work Item is not as anticipated the Product Owner can also stop the work in deference to a future sprint.
  4. Logging during retrospective
    1. 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.
    2. 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.
    3. 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[9] .
  5. Roles
    1. Roles and responsibilities should be clearly defined along with the terms, concepts and tools usage[10].

Process

  1. Anyone who has an idea can enter it into TFS.
    1. This captures good ideas on-the-fly and allows a Product Owner to be enriched by the creativity of the entire team.
    2. The Product Owner expands on these and assigns a Stack Rank
    3. Stories the Product Owner feels are not substantive ideas, he sets to a Stack Rank of 100 or discards them entirely.[11]
  2. 1st version of User Story
    1. The Product Owner documents the first version of the User Story.
    2. Ensures intent is captured independent of any prejudices or preexisting systems.
    3. Gives the owner the opportunity to flavor the entire effort.
    4. Drives the development early on from a business perspective not an IS/IT one.
  3. BSA Refinement
    1. 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.
    2. Part and parcel to this is the addition of extra elements of specification as appropriate.   These include data definitions, models, architectures and business rules.
    3. 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.
  4. Flesh out User Story
    1. A User Story is identified as a part of a thematic release by the Product Owner.
    2. BSA works with the Product Owner and SME (if assigned) to flesh out the story.
  5. Wire Framing
    1. BSA and GUI person wire frame an interface interactively with the Product Owner.
    2. 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.
    3. User stories that refer to a Wireframe will have the hyperlink to the Wireframe included as a related link in the User Story
    4. A User Story can point to more than one Wireframe and a Wireframe can be pointed to by more than one User Story.
  6. Global user stories[12]
    1. Contain general standards or requirements.
    2. They are hyperlinked to from the product level.
    3. 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.

[1] “Those who don’t know history are destined to repeat it.” – Edmund Burke

[2] Don’t become a “white elephant” though.

[3] The TFS administrator will have to add this.

[4] 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.

[5] 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.

[7] I have deliberately not included estimation techniques here, but will cover them in a future post.

[8] 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.

[9] 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.

[10] I will post something on general role definitions in a later post.

[11] Work item delete capability should be granted to a responsible Product Owner

[12] 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.

About Brian Lucas

In his life, Brian Lucas has been a coach, farm worker, forester, health care advocate, life guard, general contractor, mechanic, mixologist, musician/singer (in a rock group), salesman and teacher. Brian has worked as a project manager, technical marketer, methodologist, manager, software architect, systems designer, data modeler, business analyst, systems programmer, software developer and creative writer. These efforts include over a hundred hi-tech initiatives in almost every business and industrial sector as well as government and military projects. Among them, he designed and developed a quality assurance system for the first transatlantic fiber optic communications network, a manufacturing system for a large computer manufacture’s seven manufacturing centers, a data mining system for steel production, an instrumentation system for cable systems, defined requirements for government’s information systems and designed and developed human performance management systems. Brian has educated and mentored many over the years, designing programs to discover and develop talent. He has also lectured extensively to a variety of audiences. Brian is currently devoting as much time as possible to the innovation of business agility and human capital management along with the next generation of agile software development. As an amateur theoretical physicist he is working on joining general relativity and quantum mechanics through a multidimensional time corollary on string theory and negating the uncertainty principle with Louis de Broglie’s wave/particle hypothesis. He is also an avid blue-water sailor and wilderness backpacker. He enjoys billiards, boxing, chess, cooking, famous battle reenactments and war gaming, fencing, flying, gardening, horseback riding, martial arts (particularly Ninjutsu), philosophy and psychology, playing musical instruments (7 so far), poker, rapid-fire target shooting, reading (he tries to read a new book every night), painting with oils, scuba diving, skiing and recently writing novels.
This entry was posted in Agile Arguments, Agile for Beginners, Agile for Software Development, Agile in the Enterprise, Agile Tool and tagged , , , , , , . Bookmark the permalink.

58 Responses to Using Microsoft’s Team Foundation Server to Your Agile Best

  1. Brad says:
    August 6, 2012 at 7:43 pm

    We’re trying to expand our use of TFS on the Testing team, to replace things that we might have done with other apps in a more “hand-crafted” way. For example, we often come across new scenarios in field tickets and other interactions with the customers, that represent new test cases not yet covered. We want to add that content to our automated test assets, and we’re looking at tracking the content in TFS, instead of in yet another spreadsheet.
    It is important for everyone to use the notification functions!

    Reply
    • Brian says:
      September 17, 2012 at 7:39 pm

      All good ideas Brad, someone just has to read everyone for THE BOOK as the saying goes to make sure everyone is using TFS and doing so properly.

      Reply
  2. mark says:
    August 23, 2012 at 12:07 pm

    good tips for tfs – we struggled with maintaining some structure and organization for our user stories – I really like the product/epic/user story hierarchy you guys have created – it is a very clean way of keeping things orderly – thanks for posting this

    Reply
  3. Richard-M says:
    October 29, 2012 at 5:56 pm

    Brian – These are great tips, easy to implement and practical. Do you have anymore? I know you don’t like to make product recommendation, but I was wondering if you could comment on Sharepoint use with TFS. Thanks!

    Reply
    • Brian Lucas says:
      March 28, 2013 at 3:10 pm

      SharePoint is a good way to expose some of the non-code oriented contents from TFS. I like to see it used to show schedules and libraries of products or knowledge sharing.

      Reply
  4. Dan says:
    November 7, 2012 at 10:22 pm

    These are very good TFS tips from someone who must have actual experience working with it. Thanks Brian.

    Reply
  5. Helen Barnstable says:
    February 4, 2013 at 4:18 pm

    We are new to TFS and agile and this was a big help in getting us grounded thanks Brian!!!

    Reply
  6. Denny says:
    February 18, 2013 at 3:11 pm

    Great TFS tips thanks man!

    Reply
  7. ReeseR says:
    February 18, 2013 at 5:55 pm

    Hi Brian: How do you handle reusable components? Identifying candidates and then mining them for reuse. Thanks in advance.

    Reply
    • Brian Lucas says:
      March 28, 2013 at 3:13 pm

      Reusable components should be in a utility epic and referred to in line so to speak in the set of user stories that use it by a reference number only.

      Reply
  8. Brian Schultz says:
    February 18, 2013 at 6:27 pm

    I am happy to report that I have implemented all of these and it is working out very well. Kudos to Mr. Lucas and me as well for being smart enough to recognize a good thing when I see it.

    Reply
  9. P. Brown says:
    February 18, 2013 at 10:28 pm

    You can’t miss with these tips.

    Reply
  10. Christopher says:
    February 19, 2013 at 4:30 am

    I also got our TFS admin to implement these and it has proven to be a good thing.

    Reply
  11. BobbyG says:
    February 19, 2013 at 5:41 am

    Anymore tips in this area Brian? These were great!

    Reply
  12. Wayne says:
    February 19, 2013 at 8:14 am

    Hey thanks Brian for this post. A friend forwarded it and I can honestly say I think it will help us decide to use TFS.

    Reply
  13. FoleyS says:
    February 19, 2013 at 12:42 pm

    I’ll weigh in on the side of all the positives that have been said here.

    Reply
  14. Roy says:
    February 19, 2013 at 10:17 pm

    I love these specifics Brian do you have any others? Also do you use Excel to blow the raw data into TFS?

    Reply
  15. Frank says:
    February 20, 2013 at 1:02 am

    Our CIO is opposed to TFS do you have any alternative suggestions?

    Reply
  16. Uri says:
    February 20, 2013 at 3:57 am

    Good TFS tips. Thanks for sharing.

    Reply
  17. Dez says:
    February 22, 2013 at 1:53 am

    I also followed the TFS advice here and the other article Brian posted and it proved very helpful with our agile process management. Nice work Brian!

    Reply
  18. billy says:
    February 22, 2013 at 2:55 pm

    I also have to comment on the fact that I found these tips to be good.

    Reply
  19. Joe Barstow says:
    February 22, 2013 at 12:16 pm

    Brian do you intent to post more on TFS or any other tools that you use or recommend? That would be something I would be greatly interested in.

    Reply
  20. Elton says:
    February 22, 2013 at 3:29 pm

    Good tips Brian! We created our own template for our agile method, rather than use the scrum one from Microsoft. It is very easy to do and allows you to simplify the input of data considerably.

    Reply
    • Brian Lucas says:
      March 28, 2013 at 3:21 pm

      Exactly right! Just don’t stray too far with nonstandard functions that will make an upgrade ponderous.

      Reply
  21. Ed Morton says:
    February 22, 2013 at 3:51 pm

    What about add-ins do you use any? recommend them?

    Reply
  22. Danni White says:
    February 22, 2013 at 5:39 pm

    It makes sense to stuff everything into TFS – code, requirements, documents, pictures, etc and treat it as a repository. We use sharepoint as a portal for it. It really helps share the knowledge. Well that’s my tip Brian what do you think? Yours are right on the money!

    Reply
  23. Everitt says:
    February 22, 2013 at 5:46 pm

    Brian are you going to post more nuts and bolts of agile software development like this? For those of us on agile development teams it is something we would love to have more of. Your blog is great!

    Reply
  24. Chester says:
    February 24, 2013 at 9:53 pm

    It kind of seems to me that these suggestions are a whole package deal and you have to take them all or it won’t work. Am I right?

    Reply
  25. Wilber says:
    February 24, 2013 at 10:27 pm

    You can tell these tips were made by guys who actually use TFS daily because they all make your job easier.

    Reply
  26. Voron-B says:
    February 25, 2013 at 5:22 am

    I thought it was interesting that you use BSA (analysts) in your model we got rid of our in lieu of more seasoned developers. It has worked out well for us as far as speed and quality are concerned.

    Reply
    • Brian Lucas says:
      March 28, 2013 at 3:25 pm

      That is an often pursued model. Another is just moving the BSAs from the CIO owned branch to the user owned segment.

      Reply
  27. Cap says:
    February 25, 2013 at 6:09 am

    The products/epics/user stories approach makes a whole lot of sense!!! Makes me feel dumb for not thinking of it myself.

    Reply
  28. Sandoval says:
    February 25, 2013 at 6:19 am

    The tree view query was very helpful! Thanks Brian and Dave!

    Reply
  29. Tonya, Rose says:
    February 25, 2013 at 8:59 am

    These definatly work I have tried them. Nice simple TFS concepts.

    Reply
  30. Petri says:
    February 25, 2013 at 12:06 pm

    I’ll cast a dissenting vote her, I don’t like TFS. Nothing to do with the post though.

    Reply
  31. KulaR says:
    February 25, 2013 at 1:11 pm

    Hey Brian where have ya been you haven’t commented in awhile.

    Reply
  32. Orlando Ruiz says:
    February 25, 2013 at 2:07 pm

    I have some tips too I can share. I will email them to you and you can post them if you want.

    Reply
  33. Megs says:
    February 25, 2013 at 2:09 pm

    Yea it works for me

    Reply
  34. JaneD says:
    February 25, 2013 at 4:10 pm

    I thought this was really good too!

    Reply
  35. Barney says:
    February 25, 2013 at 4:17 pm

    Good stuff here! Nothing impractical.

    Reply
  36. Donald Schumer says:
    July 8, 2013 at 5:21 am

    This is going right into our book of standards. Thanks for posting!

    Reply
  37. Kendra Lansing says:
    July 8, 2013 at 5:33 am

    Excellent and to the point post on TFS! I was recently promoted to lead scrum master and have overall responsibility for our agile environment. This is the kind of practical structural advice that we really needed. It solved several issues we were having with user stories and tracking progress. Do you intend to do another post like this? Also I have a few questions would you mind if I emailed you?

    Reply
  38. Olive Swanson says:
    December 4, 2014 at 3:19 pm

    Great tips Brian! Thanks for posting!

    Reply

Leave a comment