Email as a medium for capturing, documenting and disseminating requirements is a bad idea

1. Developers are not trained in the art of handling clients diplomatically. If you include them in the email, they will respond as they see fit and you may be left handling the damage control. 2. The assumption that the entire development team will somehow absorb all the requirements based on emails back and forth is naive. 3. You may be setting yourself up for nasty disputes with your clients as to what exactly you committed to deliver.

You need a better way to capture requirements. If you are following the Waterfall process, use the email communication with the clients as a source of information for what goes into the requirements document that you will get the client to approve. After that any changes should be handled through change control.

However, I strongly recommend that you follow the Scrum process. Designate a Product Owner (PO) on your side to engage in this communication with the client to understand their business goal and what would constitute success in what you all are setting out to build. Then this PO should be able to work with the dev team to write user stories in the form of

As a [type of user], I want [some goal] so that [some reason].

And also write testable acceptance criteria for each such user story.

Email as a medium for capturing, documenting and disseminating requirements is a bad idea

1. Developers are not trained in the art of handling clients diplomatically. If you include them in the email, they will respond as they see fit and you may be left handling the damage control. 2. The assumption that the entire development team will somehow absorb all the requirements based on emails back and forth is naive. 3. You may be setting yourself up for nasty disputes with your clients as to what exactly you committed to deliver.

You need a better way to capture requirements. If you are following the Waterfall process, use the email communication with the clients as a source of information for what goes into the requirements document that you will get the client to approve. After that any changes should be handled through change control.

However, I strongly recommend that you follow the Scrum process. Designate a Product Owner (PO) on your side to engage in this communication with the client to understand their business goal and what would constitute success in what you all are setting out to build. Then this PO should be able to work with the dev team to write user stories in the form of

As a [type of user], I want [some goal] so that [some reason].

And also write testable acceptance criteria for each such user story.

Here is the opinion of Roman Pichler, author of Agile Product Management with Scrum, on the PO role in small teams. You will see it in the Q&A below the blog post: "I have worked with a few teams where one of the team members played the product owner role successfully. Generally speaking, I find combining the roles challenging."

Email as a medium for capturing, documenting and disseminating requirements is a bad idea

1. Developers are not trained in the art of handling clients diplomatically. If you include them in the email, they will respond as they see fit and you may be left handling the damage control. 2. The assumption that the entire development team will somehow absorb all the requirements based on emails back and forth is naive. 3. You may be setting yourself up for nasty disputes with your clients as to what exactly you committed to deliver.

You need a better way to capture requirements. If you are following the Waterfall process, use the email communication with the clients as a source of information for what goes into the requirements document that you will get the client to approve.

However, I strongly recommend that you follow the Scrum process. Designate a Product Owner (PO) on your side to engage in this communication with the client to understand their business goal and what would constitute success in what you all are setting out to build. Then this PO should be able to work with the dev team to write user stories in the form of

As a [type of user], I want [some goal] so that [some reason].

And also write testable acceptance criteria for each such user story.

Email as a medium for capturing, documenting and disseminating requirements is a bad idea

1. Developers are not trained in the art of handling clients diplomatically. If you include them in the email, they will respond as they see fit and you may be left handling the damage control. 2. The assumption that the entire development team will somehow absorb all the requirements based on emails back and forth is naive. 3. You may be setting yourself up for nasty disputes with your clients as to what exactly you committed to deliver.

You need a better way to capture requirements. If you are following the Waterfall process, use the email communication with the clients as a source of information for what goes into the requirements document that you will get the client to approve. After that any changes should be handled through change control.

However, I strongly recommend that you follow the Scrum process. Designate a Product Owner (PO) on your side to engage in this communication with the client to understand their business goal and what would constitute success in what you all are setting out to build. Then this PO should be able to work with the dev team to write user stories in the form of

As a [type of user], I want [some goal] so that [some reason].

And also write testable acceptance criteria for each such user story.