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…
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
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.