By Brian Lucas
While I don’t, as a policy, generally make product recommendations; I do feel comfortable offering tips and tricks about a particular tools use. Particularly a very popular one. 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Of course use a user story as it was intended. Here’s a bit of a process snippet:
- 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.)
- 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.
- It is at this point I usually hold a release planning session.
- 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.
- It’s at this point I usually hold an iteration planning session.
- I generally develop the acceptance criteria after any wireframing that the user story requires is mostly completed.
- I develop the test cases from the acceptance criteria and the associated completed wireframes.
- The developers usually begin their serious coding effort at this point.
- 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.
- As a user story is completed and turned over to test I begin with the user documentation.
- 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.
- 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.
I will post more tips here over time and if you are having trouble representing an agile concept in TFS let me know and I try to answer your question. So have some fun in TFS and remember till next time – keep agile.
[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.
Keeping Agile™ with Brian Lucas 
These are really great ideas. They are simple and yet will help us keep our development organized. We have done something similar, with the iteration field, but it is complex and confusing. Do you have any whitepapers on this or webinars on TFS usage for agile? I would like to watch them! Can you please share your nested query? It would be very much appreciated. I have looked at your other posts and they are the best I have ever seen. I have never followed a blog where a writer talks about why CEOs fail and deals with financial information at the level you have written at and yet covers practical tips in TFS with expertise. Keep posting……..
Thanks James! I find being narrow very boring and I avoid it at all costs.
James – I agree with you completely! Brian has a great blog with a tremendous breath and depth to his writings. The only thing wrong is he does not post everyday, but that is apparently because his company only gives him a couple of hours a week to blog. What a shame!! -Sally
Excellent Microsoft TFS agile tips. Great stuff to keep you out of trouble and keep organized. I have been using TFS as an agile developer for 7 years and started to do much the same thing after much trial and error. I like your use of epic work items. I do have a question though. In more complicated routines where there is additional documentation, where does that reside. I normally like to see the code be self documenting, but sometimes when we do works for hire we need to submit some form of specification ahead of time to get approval. Does that simply remain unattached? I would really appreciate hearing what you have to say about this, because of your obvious depth of knowledge. Thanks! TC
If more detailed information is required I attach it as documentation to the epic level that leaves the developer to frame the solution in a manner that best meets what is continually emerging from the user. Email me if you want to cover this in more detail.
Brian – I have sent these tips on to a number of developers who are friends and they all liked them. If you had the time you could do a separate blog on just agile development. – Sally
Brian – I don’t often get involved at this level of agile, but I ran your TFS tips by a friend of mine and he said they were great practical suggestions. I am curious because you seem to span such a large reach of information from detailed programming concepts in agile to high level organization knowledge and business practices. That’s very unusual! Do you have a ghost writer on one part or the other? I really am impressed with your organizational and business oriented writing. You reduce complex issues in a very clear and concise manner and identify solutions without over simplifying. Please post more articles! I am sure I speak for a number of us in this group that we would love to have a daily post from you!
One of your loyal readers
Sally Rider
No Sally its only me. Many subjects and levels of knowledge interest me from business theory to the bit design of von Neumann computing machines and not just in business and information science. I love theoretical physics, history, military strategy, philosophy, psychology, anthropology, archeology and ecology. So I naturally have to satisfy my curiosity and learn about a wide variety of subjects. -Brian
Great tips for TFS Brian. I had some of these already, but you have a number of good ideas I had not heard of. Thanks and post more if you will.
Really good technical tips. Practical and I find your breakdown structure of products, epics and stories well founded. How come you never wrote a book? -L
If I could save time in a bottle as Jim Croce wrote I could do it.
One thing I also do as a tester is to help the team count scope. Most newbie agile teams over-commit, and they work on stories that are too big. Find ways to divide the work into small chunks or threads. Make sure testing estimates are included in story estimates. Sometimes features take longer to test than to code! When you see a story that looks too big, ask if it can be divided up. Sometimes the smaller piece may not deliver much business value, but the team needs to focus on getting one small story done at a time, including all the testing activities.
That is the basis of an epic, express the large idea as a whole than break it down with a functional decomposition.
I find more of consistent value here than in any ten ogher blogs!
Brian are you up for an email on some TFS questions?
Sorry it took so long, but sure send me an email.
Hi Brian: Thank you for these tips. I have a few to share as well. Shall I email them to you and you can look them over before publishing them?
Our email stream concluded that these tips were too specific to what the company was doing in heavily modified templates to be of general help.
Would you believe our project manager who has no idea how to run a project won’t let us do this? Politics as usual.
Sad, but too often the case!
These are very good tips Brian how did you come up with them? Trial and experience or did you learn them from someone else?
Trial and experience preceded by some Prometheus like forethought!
I actually ran across some practical detailed tips on the internet? simply amazing Brian, now don’t spoil us! lol
Yep these were helpful!
I’m on board
Good stuff Brian. I am more interested in this sort of information, but its all good.
Cool TFS tips thanks man!
Hey Brian any tips on TFS add-ons?
I usually don’t make product recs
We were struggling with our TFS implementation in our new agile project and this helped. Thanks for sharing!!!
Glad it helped, keep in touch and let me know how you are doing.
Good tips, easy to understand and implement, what more can you ask for…
Good TFS tips thanks man!
Very practical and useful TFS tips thanks for sharing. I’d recommend them to everyone!
Very helpful tips,
I do have a few questions.
1. Is there a way to leverage the Epics in the default Product Backlog view?
I really like the board view but it will only show the leafs (the child PBIs).
2. The developers need to create all kinds of technical task containers and are using stories which are cluttering the product owner’s backlog, any better practices for these?
3. Have you used story mappings? I’ve found them extremely useful for brainstorming with the team but need to figure out how to translate them to the stories later on.
thanks,
Hi Eitan,
Thanks for the comment and the questions. In response to question 1, you will find the query that I use to look at the entire breakdown shown in https://keeping-agile.com/2012/07/30/using-microsofts-team-foundation-server-to-your-agile-best/. You can readily adapt this to your needs. The fun part of TFS is that it is so open ended and you can do a lot with queries. The answer to question 2 is also in that post use the global user stories for these. I also further recommend sub classing them into technical, regulatory and enterprise. This keeps the business PBI free from clutter and lets Enterprise Architects if you have them make a contribution. Most importantly in your case it allows the developers to establish containers freely without fetters and permits them to assign their scope of influence. You also might want to check out https://keeping-agile.com/2012/05/30/when-to-use-epic-user-stories/ for the decomposition process that I use.
Finally, I am fond of user story mapping, the child of the system flow diagram or conceptual model. The modeling was based on Constantine’s and Lockwood’s Task modeling. From an electronic tool perspective I have used Agile User Story Map for JIRA. User story maps are great in the brainstorming sessions as you noted, when you are often dealing with epics. As the user story map gets fleshed out with more detail it breaksdown in a natural way into atomic user stories. The utility of the map changes after initial planning and it becomes a Kanban production bulletin board. These all get directly entered into TFS either through an electronic interface or mechanically. I favor an electronic tool just for convenience sake. Even when you are not working on a distributed agile project having artifacts in an electronic form is nice. Particularly for people like me that keep weird hours. Let me know if this answers your question.
–Sincerely
Brian Lucas