Support for single team working on multiple projects

Edit Subject

This one has been asked for in various other threads but often as a comment on a different idea. So here is one main topic where all the votes can be collected. Let's see how far we can get :-)

Basically we have an urgent need for an elegant solution that would allow us to do the following:

- Define multiple projects, each with their own backlog. One single team is working on all these projects.

- We need to have two different "views": one where we see all the stories of all the projects together, for example to allow everyone on the team to see the full list of their work regardless the project the work belongs to, or to have an overview of all the stories in the current sprint. A "current iteration burn up" chart would be most useful at this aggregated level. We also need to be able to see the stories of the individual projects in isolation. This view is useful to discuss the priorities of the stories from one project with the product owner, for example, or to perform release planning for a specific project.

- The team velocity has to be calculated based on the delivered work of all the projects. To guide PT when automatically adding stories from the backlog to the current sprint, it would be nice if we can allocate on a per sprint basis a percentage of the resources that goes to each project. We can use commit mode to fine-tune the sprint backlog of each individual project.

I see two main new PT concepts that would implement this idea:

1) A universal filtering feature.

- In this approach, we could put all stories of all our projects (let's call these user projects) into one single PT project and tag each story with the user project it belongs to. This gives us the overview.
- A filter can be made active that would only show the stories that match the filter. This is somewhat similar to the current search function of PT, but instead of opening a new view with the search results like search currently works, a filter would keep all the current views like Done, Current, Backlog, Icebox, etc. and show only the stories in these views that match the filter criteria. Graphs should also be based on the filtered stories. This way we can add filters that show only the stories of a particular user project, and graphs such as a release burn down would also need to be based only on the filtered stories.

2) Support for project nesting.

- Here a super-project or parent project would automatically group all the stories of the sub-projects, and all the functions of the parent project work on the set of stories of all the sub-projects.
- Ideally the parent project has not just a read-only report/dashboard function but it would be fully editable just like any PT project. Under the hood PT would need to maintain the link to the sub-projects such that when I drag a story in the parent project from the backlog to the current sprint in fact this story is moved in the sub-project and the parent project view is updated.
- One level of nestng would already be a mega huge improvement.

The advantage of the project nesting approach is that there is no need to tag each story, so this approach seems to be the better implementation of the idea, however I can also imagine that the filter approach is more generally useful so that other people may benefit from it even if they do not need to work wih multiple PT projects.