I think you're right - in general, users should not be contacting developers directly. There may be some cases where it is appropriate for users to be working and communicating directly with the development team, but it's the exception rather than the rule. Generally, WBW is right - figure out explicitly what the problem being caused by this direct contact is and be able to clearly state it.

There are a few things that need to happen here.

First, whoever is responsible for IT should restrict who can send things to the development distribution list. People who don't have a need to send things to the entire development team should not be able to send messages to it. This sounds like a configuration issue that should be resolved through whatever systems or services manage your distribution list.

Second, the ScrumMaster and/or Agile Coach should be involved. The job of the person in this role is to understand the process that the team is following and educate all stakeholders on what the process is and why following this process is beneficial.

Since you mention that the people sending emails are internal to the company, it is likely that they have access to internal address books or contact lists. If these people contact developers, developers should not spend significant time contacting or replying to these emails. If these communications are outside the team's process, the Product Owner and ScrumMaster should be involved to (1) end these distractions and (2) take ownership of prioritizing and responding to user feedback.

I think you're right - in general, users should not be contacting developers directly. There may be some cases where it is appropriate for users to be working and communicating directly with the development team, but it's the exception rather than the rule. Generally, WBW is right - figure out explicitly what the problem being caused by this direct contact is and be able to clearly state it.

There are a few things that need to happen here.

First, whoever is responsible for IT should restrict who can send things to the development distribution list. People who don't have a need to send things to the entire development team should not be able to send messages to it. This sounds like a configuration issue that should be resolved through whatever systems or services manage your distribution list.

Second, the Scrum Master or the equivalent coach should be involved. The job of the person in this role is to understand the process that the team is following and educate all stakeholders on what the process is and why following this process is beneficial.

Since you mention that the people sending emails are internal to the company, it is likely that they have access to internal address books or contact lists. If these people contact developers, developers should not spend significant time contacting or replying to these emails. If these communications are outside the team's process, the Product Owner and Scrum Master should be involved to (1) end these distractions and (2) take ownership of prioritizing and responding to user feedback.

I think you're right - in general, users should not be contacting developers directly. There may be some cases where it is appropriate for users to be working and communicating directly with the development team, but it's the exception rather than the rule. Generally, WBW is right - figure out explicitly what the problem being caused by this direct contact is and be able to clearly state it.

There are a few things that need to happen here.

First, whoever is responsible for IT should restrict who can send things to the development distribution list. People who don't have a need to send things to the entire development team should not be able to send messages to it. This sounds like a configuration issue that should be resolved through whatever systems or services manage your distribution list.

Second, the ScrumMaster and/or Agile Coach should be involved. The job of the person in this role is to understand the process that the team is following and educate all stakeholders on what the process is and why following this process is beneficial.

Since you mention that the people sending emails are internal to the company, it is likely that they have access to internal address books or contact lists. If these people contact developers, developers should not spend significant time contacting or replying to these emails. If these communications are outside the team's process, the Product Owner and ScrumMaster should be involved to (1) end these distractions and (2) take ownership of prioritizing and responding to user feedback.

I think you're right - in general, users should not be contacting developers directly. There may be some cases where it is appropriate for users to be working and communicating directly with the development team, but it's the exception rather than the rule. Generally, WBW is right - figure out explicitly what the problem being caused by this direct contact is and be able to clearly state it.

There are a few things that need to happen here.

First, whoever is responsible for IT should restrict who can send things to the development distribution list. People who don't have a need to send things to the entire development team should not be able to send messages to it. This sounds like a configuration issue that should be resolved through whatever systems or services manage your distribution list.

Second, the ScrumMaster and/or Agile Coach should be involved. The job of the person in this role is to understand the process that the team is following and educate all stakeholders on what the process is and why following this process is beneficial.

Since you mention that the people sending emails are internal to the company, it is likely that they have access to internal address books or contact lists. If these people contact developers, developers should not spend significant time contacting or replying to these emails. If these communications are outside the team's process, the Product Owner and ScrumMaster should be involved to (1) end these distractions and (2) take ownership of prioritizing and responding to user feedback.