Currently you can make work item fields READ-ONLY for certain groups of users. We would like to have the ability to hide fields or to mask the value of the field as well based on security permissions.

For example we require our PM's, Dev's and QA's to enter time estimates for enhancements and defects. These are values that we don't want our Sales/Consulting teams and potentially End-Users from seeing.

I would like to have folders for my build definitions in Team Explorer that allow me to organize and apply batch updates to several definitions at once. I could apply security to the various folders which would be inherited by the build definitions underneath. Batch updates could include regular expression modification of the build definition names, workspace folders, drop locations, and/or projects to build.

Work Items currently already have revisions saved and make them visible by looking at the history tab, however this should be a first class feature. Allow users to navigate back and forth in time, compare versions and most importantly, let work item template editors specify which attribute and state machine changes trigger a major (x.) or minor (.y) change. For example changes to the 'Description' field in our environment always causes a major change from e.g. 1.0 (or 1.1, 1.2 etc) to 2.0. Same goes for status state changes from 'In Review' to 'Released'.

Currently, to get these features into a CI build, we have to pass a lot of MS Build properties around. Having gone through the trouble of creating my own templates to handle these features, it would be nice to see them included out of the box.

Adding working hours and days off to the user profile will allow members to take responsibility of their working hours, making capacity planning easier.

A project administrator may also need to be able to update these for a user, for cases of unexpected absence, etc...

make it easy to split team projects into multiple team projects, moving work items between them.

For example, I want to prevent the creation of Sprint Tasks before a Product Backlog Item is ready for development, assigned to a Sprint, contains a description, and is prioritized.

I really like the new feature (may be) in TFS where you can add capacity in the sprint which estimates work by activity.

currently a developer can spend 2/3 of this time in development and 1/3 in bug fixing(testing). so, i would like to see two/more entries per team member to divide their capacity across different activities and properly track the project activities (dev, test, requirements etc etc)

hope you got what I am trying to say.

Build definitions should be able to query (customizable) NuGet feeds (HTTP/HTTPS) & download packages referenced by the solution(s) - as we don't want them in source control (setting?).
In addition, build definitions should be able to create, push & publish packages to any NuGet feed.
This should be possible and configurable out-of-the-box, without any customization.

It is currently only possible to move files one by one in TFS source control, which means that it takes a lot of time to move several files from one place to another place. It would be great if one could select multiple files and move them to another place at once.

We have outside auditors come in and they want to see stuff like who gave Jerry Project admin rights and when and how long did he have it? Items like that It would be nice to find info like that. It would also be nice to be able to export all of the users of a project in the groups that they are in.

You can set rights in TFS on a lot of different levels. On Team Project, Area/ Iteration/ Team Queries, Source Control/ Folders/ Files, Builds / Reports / SharePoint. Especially in TFS with different TFS groups that sometimes contain the same users/groups, it is hard to see why a user has a specific right or is not allowed to do something. At the moment it is hard to find this without checking everything manually.

This would show which files are currently checked out and how long they have been checked out. Would improve transparency within teams to see how long developers are going without checking in code.

For example if you could assign a color to an area, then the task cards would be colored to that area

Allowing federated authentication for TFS in Azure (tfspreview.com) so that we can manage our users internally

It would be very useful if TFS has the ability to merge multiple, non-continuous changesets in a single operation.
This would eliminate the need to create too many branches for each development project.

...for example, change an existing work item from an Issue to a Bug, etc.

Users less familiar with the system frequently enter work items using the wrong work item type. Currently, you can't fix these items.