difference between Product Backlog Item and Feature in Team Foundation work item types

Question

I have a question about Microsoft Team Foundation. In Visual Studio, Team Explorer, I can create a new work item. Work item types here are dictated by your team's chosen process template; I'm not sure which process template we're using. In any case, in Team Explorer, when I want to create a new work item, I'm given a list of work item types to select from, among which are "Product Backlog Item" and "Feature".

I noticed a difference between the two types related to the target resolution date. For a Product Backlog Item, this would seem to be dictated by the iteration end date. For a Feature, it's not as clear. A Feature is also associated with an iteration (and iteration end date), however Feature also has a separate field called "Target Date". The mouse hover text for target date is "The target date for completing the feature".

Should I choose "Product Backlog Item" or "Feature" as the work item type for my new work items? What's the difference between the two?

Answer 1

It looks like you are using the Scrum process template. The TFS site has published some very brief information about Product Backlog Items and Features and the idea behind creating a new work item type. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx

The difference between the two comes down to what granularity you want to work with your work items at:

• Product Backlog Items are composed of Tasks and have estimated effort.
• Features are composed of Product Backlog Items and have target dates.

I have not been able to find any official guidance on when to use Features vs Product Backlog Items but I have created my own guidance which I am basing this answer on... http://www.nsilverbullet.net/2013/06/04/features-help-us-plan-work-better-in-team-foundation-service-scrum-process/

Should you create a Feature or a Product Backlog Item?

• If you think/hope that the new work item that you are going to create will fit into a single sprint you should create a Product Backlog Item and then break it down into tasks for your sprint.
• If you think/know that the new work item won't fit into a single sprint you should create a Feature and identify all the value-providing sprint sized items (Product Backlog Items) that the Feature can be broken down into and use these when planning future sprints.

[Update 2014-05-19]

Microsoft have published more information on how to use Features and the agile portfolio concept that has been implemented in TFS https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx

Answer 2

As TFS applies an agile development strategy I think we can say:

Feature = Epic, Backlog item = Story

The epic contents similar stories.

Answer 3

I had the same doubts as OP and my thoughts has been aligned with @josant answer, which is very reasonable to me.

On the other side I'm using the Hundhausen book[1] as a reference for adopting TFS+Scrum.

He said things like:

A feature is a discrete unit of functionality that delivers value to the user or business. A PBI may be large enough to have several features.

and then:

A feature may break down into multiple scenarios. A scenario is a narrative that describes a workflow or sequence of steps through the feature that exercises one path toward achieving an expected result.

and continues developing these ideas.

To me, Hundhausen seems to be talking about use cases[2], but still I feel his proposal some counterintuitive, neither seems TFS would be guiding to this analysis method orb I found it referenced in the scrum literature I read.

Probably it's just a matter of choosing a convention you feel more confortable with and adhere to it.

[1] http://www.amazon.es/dp/073565798X

[2] https://en.wikipedia.org/wiki/Use_case

Answer 4

A Feature is a Product Backlog Portfolio.

http://tfs.visualstudio.com/en-us/learn/create-your-backlog.aspx

Answer 5

Feature is a level up to 'backlog items'. team defines work as high-level initiatives and breaks them down into features. which further break down and define the work to be done as 'Backlog'. ref http://msdn.microsoft.com/en-us/library/dn306083.aspx?

Answer 6

As others said here:

• Features: Top Level
• Backlogs: One Level below Features (a feature is made of backlog items)

Keep in mind that you can LINK work items and you can display them as a Tree List. So, you can link a backlog item to a feature, and later, you can link a task to a backlog item. Thus, you get a nice hierarchical tree list.

Answer 7

This is how I use it. Under the tool items "Work" -> "Backlogs" both "Features" and "Backlog Items" are listed. I start with features so there are no backlog items at that point. I add the features by selecting Features under the Backlog header and adding the Feature name in the form then saving and closing. To the left of each newly added Feature there is a green + sign. Click on the plus sign and selection options appears. Choose "Product Backlog Items". When it opens type the name of the backlog item in the top field just like in Features. You are creating these backlog items, there is no pop-up. Fill in the other information as required then save and close. After creating the Backlog items click the green + on the newly created Backlog Items. Enter the name of the work item like you did for the Backlog Items and the Features. When adding the work items include the sprint in the iteration field and they will be in the sprint when you open it. None of this is documented anywhere that I could find. I hope it is in sufficient detail.