difference between Product Backlog Item and Feature in Team Foundation work item types
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
As TFS applies an agile development strategy I think we can say:
Feature = Epic, Backlog item = Story
The epic contents similar stories.
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
A Feature is a Product Backlog Portfolio.
http://tfs.visualstudio.com/en-us/learn/create-your-backlog.aspx
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?