Normally, we plan releases based on deadlines. And based on that we plan both the required CRM environments, and also, very important, TFS branches.
A typical workflow might go through the following stages:
DEV -> TEST (UAT) -> Staging -> Production.
If you're gonna have concurrent releases where you release Sprint 1, and then Sprint 2, there will be an interim period where Sprint 1 will be in live while still developing Sprint 2. You really need a Staging environment which should mimic production because you might need to fix issues for Sprint 1, which is live, while still developing features for Sprint 2, in other environments.
Therefore you normally want to keep those in 2 different environments and TFS branches.
So, for example, while developing Sprint 1 you might be in the following situation:
Sprint 1
- DEV (where you actually develop new features)
- TEST (where you deploy features which are ready for testing)
- Staging (nothing there yet)
- Production (nothing there yet)
While working on Sprint 2 you might have :
- DEV (where you develop new Sprint 2 features)
- TEST (where you test Sprint 2 features ready for testing)
- Staging (which you leave with Sprint 1 only for potential bug fixes)
- Production (still with Sprint 1 stuff)
After Sprint 2 release all environments will match, and then start again.
That was just one example. Depending on the number of dev teams and releases can get even more complicated.