我有一个关于 Microsoft Team Foundation 的问题。在 Visual Studio 的团队资源管理器中，我可以创建一个新的工作项。此处的工作项类型由您的团队选择的流程模板决定；我不确定我们使用的是哪个流程模板。无论如何，在 Team Explorer 中，当我想创建一个新的工作项时，我会得到一个可供选择的工作项类型列表，其中包括“产品待办事项”和“功能”。
我注意到与目标解决日期相关的两种类型之间存在差异。对于产品待办列表项，这似乎是由迭代结束日期决定的。对于一个功能，它并不那么清楚。Feature 还与迭代（和迭代结束日期）相关联，但是 Feature 也有一个单独的字段，称为“Target Date”。目标日期的鼠标悬停文本是“完成功能的目标日期”。
我应该选择“Product Backlog Item”还是“Feature”作为我的新工作项的工作项类型？两者有什么区别？
看起来您正在使用 Scrum 流程模板。TFS 站点发布了一些关于产品待办列表项和功能以及创建新工作项类型背后的想法的非常简短的信息。http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx
两者之间的区别归结为您希望以何种粒度处理工作项：
我无法找到有关何时使用功能与产品待办事项项目的任何官方指南，但我创建了自己的指南，我将这个答案基于... http://www.nsilverbullet.net/2013/06/ 04/features-help-us-plan-work-better-in-team-foundation-service-scrum-process/
您应该创建功能还是产品待办列表项？
[2014-05-19 更新]
Microsoft 已发布有关如何使用功能和已在 TFS 中实施的敏捷组合概念的更多信息https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx
由于 TFS 采用敏捷开发策略，我认为我们可以说：
特征 = 史诗，待办事项 = 故事
史诗内容类似的故事。
我和 OP 有同样的疑问，我的想法与@josant 的答案一致，这对我来说非常合理。
另一方面，我使用 Hundhausen 的书 [1] 作为采用 TFS+Scrum 的参考。
他说过这样的话：
特性是为用户或业务提供价值的独立功能单元。PBI 可能大到足以具有多个功能。
接着：
一个功能可以分解为多个场景。场景是描述工作流或步骤序列的叙述，通过该功能练习实现预期结果的一条路径。
并继续发展这些想法。
对我来说，Hundhausen 似乎在谈论用例 [2]，但我仍然觉得他的提议有些违反直觉，似乎 TFS 也不会指导这种分析方法，我发现它在我阅读的 scrum 文献中被引用。
可能这只是选择一个你觉得更舒服并坚持它的约定的问题。
功能是“积压项目”的一个级别。团队将工作定义为高级计划并将其分解为功能。它进一步分解并将要完成的工作定义为“积压”。参考http://msdn.microsoft.com/en-us/library/dn306083.aspx？
正如其他人在这里所说：
请记住，您可以链接工作项，并且可以将它们显示为树列表。 因此，您可以将待办事项项目链接到功能，稍后，您可以将任务链接到待办事项项目。因此，您会得到一个很好的分层树列表。
这就是我使用它的方式。在“工作”->“待办事项”工具项下，列出了“功能”和“待办事项”。我从功能开始，所以那时没有积压项目。我通过选择积压标题下的功能并在表单中添加功能名称然后保存并关闭来添加功能。每个新添加的功能的左侧都有一个绿色的 + 符号。单击加号并出现选择选项。选择“产品待办事项”。当它打开时，在顶部字段中键入积压项目的名称，就像在功能中一样。您正在创建这些积压项目，没有弹出窗口。根据需要填写其他信息，然后保存并关闭。创建待办事项后，单击新创建的待办事项上的绿色 +。输入工作项的名称，就像您为待办事项和功能所做的那样。添加工作项时，在迭代字段中包含 sprint，当您打开它时它们将在 sprint 中。我能找到的任何地方都没有记录这些内容。我希望它足够详细。