Your question is tagged with scrum. Therefore, the answer should be based on Scrum, not the tool you're choosing to use, which in this case is tfs.
You can fix your process problems by:
- Participating better in Scrum ceremonies, and sitting with your team.
- Tracking progress towards Sprint Goals rather than focusing on utilization. See also: 100% utilization fallacy.
- Follow the Scrum pull-based queuing system, rather than assigning work.
Each of these solutions are discussed in more detail below.
The Scrum Master is a Team Member Too!
Using TFS I would like to see the status of team members.
This is a project smell. As the Scrum Master, you should be actively involved in all team ceremonies, including daily standups and planning meetings, so even if you're correctly avoiding status pulls, you should still have a fairly good idea of what the team is doing at any given point in time. If you don't, then ask.
Good Scrum Masters can participate in two or three Scrum Teams, but great Scrum Masters participate in only one! If you aren't an intrinsic part of the Scrum Team, then you aren't really practicing Scrum or leveraging the full power of the framework.
Note that Scrum doesn't forbid status pulls outside of its prescribed ceremonies. However, status pulls are often a signal that you aren't sitting with your team, or participating properly in their meetings, ceremonies, or other activities. If you have no idea what your team is doing, you're not participating enough, or practicing good servant-leadership. Fix that!
Track Team Performance, Not Individual Utilization
There is an option to write queries for tasks. But my purpose is to have a list of members that have active tasks for the current sprint and other members with empty list of tasks at the same time.
All work for a Scrum Team is self-organizing and pull-based. As the Scrum Master, you should have zero interest in how busy team members are. Rather, you should be focused on whether or not the team is meeting the Sprint Goal, and tracking burn-down to identify process problems that might endanger the Sprint Goal.
Whether or not a given user has stories, tasks, or chores assigned is entirely irrelevant to Scrum Team performance because queries such as the one you're after don't capture swarming, pairing, just-in-time or ad-hoc planning, or other typical agile practices.
Scrum Development Teams Pull Work
The Development Team in Scrum is solely responsible for what work is accepted into a Sprint. Therefore, anything that smacks of assigning work to the team—and especially to individual team members—violates both the principles of the Scrum framework and the principle of self-organizing teams that underpin it. The Product Owner or Scrum Master should never be assigning work to individuals. If you're doing that, you're not doing Scrum.
Having said that, there are certainly cases where it's useful to know who is working on a given task. Some teams use colored stickers, or write their names on the index cards of a physical story card. Electronic tools, especially those that are based on ticketing systems where each story or task has a single owner, don't really let you do that in a way that reflects agile practices. In such cases, you should either:
- Let the team coordinate their own stories, and just ask around if you lose track of who's involved in what. As you shouldn't have to do this often, it's a low-overhead approach to a rare problem.
- Assign an "owner" to the story if you must, but use story/task notes to track who's actually involved in working together on it. For example, some teams allow one person to take "ownership" of a story to shepherd it through the Sprint, even though multiple people will be involved in getting the story to Done. While I consider this a mild anti-pattern, it can be useful in larger implementations to save on status pulls.
- Switch to a tool that allows multiple team members to assign themselves to a story or task. For example, GitHub Issues allows up to 10 people to be assigned to a single issue, which is more than adequate for Scrum teams that follow the best practice of having around 7 people (plus or minus two) per team.