TFS Branching

All developers need to check-in their changes into trunk/dev branch only. As soon as someone check-in their code it is better to run a CI build (Continuous Integration) to make sure that new changes haven't caused any issue in existing code. If you are using TeamCity then you can add as many Unit tests as you want and be able to verify them after CI build is completed to make sure you are good with the latest check-in.

Once CI is good then you can push those changes into a Stagging branch where you can deploy your code to QA/Stagging area and have your testers do an end to end testing. After all, tests are completed and the code base is ready for production then it is better to tag this branch with the release date or any identification which we can use in future if you need to release a hot fix for specific release.  

Example:

Let's say you are planning to release something for March 2016 then below are branches that you can have for that release.

Dev branch: trunk ( all developers can check-in into this branch).

Code from trunk should be able to deploy to development branch for developers to run some tests. Before moving code to stagging/QA.

Stagging:  master (Code is ready for stagging area for QA testing). The code will be deployed to QA servers and handed over to testers for their testing.

Production: master_march2016_release ( You can name it something like this, it is better to follow certain naming convention within your team or firm to be consistent)

Note: Once you have deployed code to production, no one should access "master_march2016_release" branch anymore.

Best Practices: https://www.simple-talk.com/opinion/opinion-pieces/branching-and-merging-ten-pretty-good-practices/

all posted answers are very good and constructive