Уверен, многие знакомы с полями рабочих элементов "Found In" и "Integrated In", с помощью которых можно связать, например, дефект с той сборкой программного продукта, в которой он был найден, или сценарий использования с той сборкой, в которой он был реализован. Это ускоряет и разработку, и тестирование, так как Quality Assurance больше не надо тратить время на выяснение того, какую именно сборку нужно проверять, а разработчикам - на  попытки воспроизведения дефектов, которые тестировщик нашел в сборке 10-дневной давности,  и которые давным-давно исправлены

Особенность полей Found In и Integrated In - автоматическое заполнение списка доступных значений номерами всех когда-либо производившихся в рамках данного группового проекта сборок. Эта "уличная магия" работает на самом деле очень просто - для каждого группового проекта при завершении первой же сборки в Team Foundation Build создается глобальный список с названием "Builds - <Имя группового проекта>". В дальнейшем список пополняется при завершении каждой последующей сборки. В описаниях самих же полей правило SUGGESTEDVALUES просто ссылается на вышеупомянутый список.

Есть, правда, один нюанс. Если вы копируете описание типа рабочего элемента (Work Item Type Definition) из одного группового проекта в другой (или импортируете тип рабочего элемента из файла), обязательно проверьте набор правил для полей Found In и Integrated In. Скорее всего, вам нужно будет исправить или вовсе удалить (если в групповом проекте еще не производилось ни одной сборки) ссылку на глобальный список - в противном случае, Team Explorer будет вам "подсказывать" неправильные номера сборок.