Apart from the technology itself, the introduction of the Agile Portfolio Management in Team Foundation Server and Service has a huge impact on the surface you can cover on your project.
Beware: in most of the cases, I am talking about mid-sized to big projects. Introducing a concept like this in small projects could be counterproductive.
As far as now, the most common way of tackling agile product management is to create some User Stories and then split them into tasks. This is perfectly fine and it is not changing, but sometimes you can face the following problem: the User Story is too big for being delivered in a sprint.
Unfortunately it happens. So to solve this, you have to use the Epic concept.
An Epic is basically a very big User Story, which is split into several sub-Stories whose effort is compatible with the Sprint duration. Think about it as a goal. An Epic contains one or more User Stories, kept together by a common topic. You won’t deliver an Epic in one sprint, usually an Epic is a big part of the product, a (marketable) feature. You manage this on top of the product, as it can impact other products in your organization.
The Theme is on top of everything. Talking in terms of a project, it can be a major release. It is an initiative, one of the cornerstones of the project itself. Themes drive the strategy, and they express a direction – they are generally not too specific because of it.
At the moment in Team Foundation Service (and soon in Team Foundation Server 2013) you’d get the Epic concept out-of-the-box. But as Brian Harry told us in his post, it is possible to customize the experience with a low effort.