Can ONE Team Project Collection idea work for large enterprises?

I guess you would have noticed TFS Internal usage statistics in the VS ALM blog. If not, here is the link http://blogs.msdn.com/b/visualstudioalm/archive/2013/08/20/tfs-internal-usage-statistics-1st-half-cy-2013.aspx

The reason I'm writing this post now is to share some interesting readings from the article and coincidently those seem to answer a lot of guesstimated limitations/questions with real data from a large enterprise J

So, the question that is being asked fairly often:

We are a large, geographically distributed, complex product team. We believe that we need at least ONE Team Project Collection per Product. When you propose ONE Collection at organization level, which raises interesting thoughts…

• ONE collection won't work for complex organization like us (, with some curious guestimates)
• We'll max out and can't create work items and areas pretty soon
• We'll max out number of source code files
• Can't support number of branches needed the way we work
• One Collection = One Build Controller. We are running with 10s of build machines.. how will that work?
• One collection = single point of failure, what if the collection DB crashes.
• and many more..

While ALM Rangers guidance explaining the pros and cons of each strategy, ONE collection ONE project seems to embrace and offer the best ALM benefits. Especially, in TFS 2013, Enterprise Agile features are scoped at Team Project Level.

So, I thought some inferences from the latest TFS Internal usage data @ Microsoft could help us to understand the tool design, best practices better with factual data.

If we look at the data

1. Team with largest number of unique users (4,573) works in ONE collection
2. Team with largest number of unique users (4,573) has 3 Team Projects
3. Team with highest number of Work Items (1,300,350) has ONE collection
4. Team with highest number of builds per month (111,185) works in ONE collection
5. Team using ONE collection has 58132 Test cases
6. Maximum number of collections by any team is 3, ~50% of the teams (14/30) with total ~15,000 users are using ONE collection
7. Team with largest number of source files (8,017,824) has TWO collections
8. Team with highest number of Test Cases (308,242) has THREE collections

On the other side, there are number of the projects use >10 Team Projects, however, I do see something called Consolidated and I guess they were consolidated from several collections/team projects to few (example, Instance 4, Instance 6) or under consolidation.

Overall, It's easy to fork, create more Team Projects and Collections along the way, if things don't work. However, it's extremely hard to merge them when needed. There is no silver bullet or tool that works quietly. I've seen people frustrated, stopped the consolidation effort and started from clean slate all over again.