Keeping your stories in TFS (team foundation server)

This of course applies to other systems, we've been using story cards, Sharepoint and Excel, and the attributes or columns become about the same.

When keeping your product backlog in TFS, you can define one work item type and make this apply to all your stuff on the product backlog. As I've discussed earlier, you will probably have other stuff than stories on your backlog: you could have technical stuff as upgrading your development environment or setting up your testing environment. You could also have your bugs on your product backlog. In many templates, there are only one work item type for your product backlog item. The good thing about this is:

• You don't have to think about how to classify the new item when you're about to create them. Is this a bug, or a story?
• It is easier to configurate your product backlog queries since you're only working with one kind of work item. I know it's a hard nut to crack, but writing nested queries is never easy for me if I'm forced to use a graphical tool. TFS is no different.
• It is easier to change type and form. If you've created a work item you cannot change the work item type. Yes, you can copy to another work item, but the links are then towards the old work item...

The things that speaks against using one work item type is that if you have different stuff on your product backlog, you will probably classify these different types with different attributes. You will only have one state machine and the state options have to take all types into account. For example, if you have bugs on your product backlog, then you might want a state for unconfirmed bugs. This will probably not apply to stories. Also, it is easier for users to see what type of work item they're viewing: helpdesk might only be interested in bugs. The latter problem can of course be solved by adding a combo in which the user specifies type.

We have a specific work item type for stories. These are the attributes:

• Title.
  Short description of story in the form As a x user, I can y, so that z
  
• Description
  Notes from business people, which can help in understanding objective
  
• Definition of Done
  We have a Definition of Done written down. This applies to all stories. If this does not applies or have more things on the specific story: this will be added here
  
• Importance
  Value which only should be changed by Product Owner. We use a falling scale, in which 10000 has been the highest and 0 the lowest. I tend to use a broad scale, for example at least 9 between items (1990, 1980) to make it possible to easily slip in a new story between other stories. I can also use the number series as grouping (all stories 1990-1010 are related)
  
• Story points
  Owned by the team for their estimations (story points)
  
• How to demo
  A list of things that should be demoable
  Tests which should be performed but might not be obvious to the developer or tester
  
• State
  In which state the story is
  
• Assigned to
  This is most commonly used when a story is not understood or cannot be estimated by the team. The state of the story is then set to Draft and is assigned to the individual who will take responsibility for making the stuff clear.
  
• Sprint
  The sprint during which the story is completed.
  
• Source
  Who is the source of the story. The person who best should be able to answer questions or validate the solution
  
• PFC
  We have a product feedback center in which we log customer feedback. If an item in the product feedback center is addressed, this is entered here
  
• Epic
  
  
• Theme

I'll be going into details into some of these attributes, if there is something special you have questions about, feel free to ask