While this is an old question with an accepted answer, I believe that there is still room for another one.
First, let me say up front that I don't think Features is the right tool for this task, and shall propose an alternative set of tools.
A prerequisite for team collaboration is to have a staging server for testing out development versions of the project that is separate from your production server. All devlopment code is tested at the staging server, and only pushed to production server when it is stable and ready for deployment. However, the developers doesn't work directly at the staging server. Each developer work at his or her own workstation, using a revision control and source code management (SCM) to coordinate his or her work with the rest of the team.
The SCM system allow team members to work in parallel on different branches of the code without interfering with each other. Only the master branch is deployed on the staging server for testing purposes.
To mirror the database between production, staging and workstations, there is a module named Backup and migrate that can be used if you're on shared hosting and not managing your own database. If you're managing your own database server, this is the only project on that server, and you use mysql, the following pair of commands are handy:
mysqldump --all-databases --opt -u root -p > DUMP.sql
mysql -u root -p < DUMP.sql
If yours is not the only database on that server, script some version of
mysqldump (or equivalent if you're not using mysql) that dumps your databases only.
Make a policy that it is the database on the production server that is master. The staging server and workstations should be a copy of the production database, not vice versa.
Note that Drupal 7 keeps all its admin setting in the database. This means that mirroring the database between the production site, staging site and workstations will migrate admim settings without Features.
Now, for sharing the code:
The standard way for sharing code among the members of a development team is to use SCM system. Drupal happens to be default be managed with such a system named git.
Git allows the use of local or remote repositories. If the team members are located in the same physical space, you can set up a local repository on your staging server. If they're spread geographically, you can set up a remote repositiory. If you don't mind others having read access at your code under development, you can use a sandbox at Drupal.org as a remote repository. You can also use a project area on GitHub. GitHub is not only a repository, but comes with a some tools for collaboration, and allows both public and private repositories.
Basically, a SCM system allow team members to pull source code and documentation from the respository shared by the team members, and push it back in again after having worked on it. The SCM keeps track of changes and if there is a conflict (i.e. somebody tries to push code that doesn't the contain the changes another team member has committed), it will tell you and also suggest a way to resolve this conflict.
Usually, with some cordial communication about how the tasks are divided among the members of the team, there will be no conflicts. But with the SCM system keeping track of things, conflicts become manageable even if mistakes are made or communication fails.
There exists a lot of tutorials on getting started with and using git (GIYF). Two I will recommend are: the git-scm website and Pro Git by Scott Chacon.