Using TFS I would like to see the status of team members.

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.

How can I achieve that in TFS?

  • 5
    I smell an XY problem. Why are you concerned with whether or not someone is busy? Just because they don't have an active task doesn't mean they're not doing something. Maybe they're pairing with someone, or mentoring a Jr. Be wary of the 100% utilization fallacy.
    – RubberDuck
    May 18, 2017 at 11:04
  • 1
    Assigning tasks to individuals is a Scrum anti-pattern. All that matters is that a story or task is available to be pulled by the team.
    – Todd A. Jacobs
    May 18, 2017 at 13:16
  • scrumguides.org scrum.org May 21, 2017 at 21:02

1 Answer 1



Your question is tagged with . Therefore, the answer should be based on Scrum, not the tool you're choosing to use, which in this case is .

You can fix your process problems by:

  1. Participating better in Scrum ceremonies, and sitting with your team.
  2. Tracking progress towards Sprint Goals rather than focusing on utilization. See also: 100% utilization fallacy.
  3. 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.

Important Tip 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:

  1. 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.
  2. 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.
  3. 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.
  • Thank you for the answer. I agree with your position. We are in the beggining of using scrum. Therefore we have some misunderstanding. And our sprint backlog is not good enough. We don't assign task to team members but try to understand is that system of pulling tasks understood by them. I will follow your advice. Thank you again. May 18, 2017 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.