Relationship between Work Items is something important to me.
The first thing that is obviously missing is a sense of hierarchy. Hierarchy is everywhere in life, so it is in a project management. Of course you can live without this notion in Team System thanks to Areas and Iterations, but it’d cost you more time to manage things if you can’t relate your Work Items with a parent/son relationship.
Here is a concrete case of what I wanted to be possible: 
Project management becomes easier, and programmers’ life too.
Yellow stars are Change Requests, Green checks are Tasks, Red crosses are Bugs, and the Warning-like icon is an Issue.
Change request are owned by Project Leaders, Tasks are assigned to developers, Bugs are created by the Testing Team, and Issues are declared by users when they can’t complete a given task due to an external reason.
A picture like that talks a lot more than a Query result on a given Area, don’t you think?
Another benefit of the hierarchy, and it’s not the least one, is you can make Work Items interacting each other automatically.
For instance:
- When a developer starts a task by setting it active, the parent Change Requests turn to active too (and your project leader knows by email that a development is starting).
- When all the tasks are closed, the owner Change Request becomes Resolved, and is waiting for approval from the Testing Team to be Closed.
- There are many other examples we could mention, like being aware when an Issue you created was solved, knowing that you have to start a Code Review, knowing your code was approved and you can check-in, etc.
Profiles
