I would like to say up front that I am no specialist in Agile development and have been using it with my team for just over a year. However, in this year I feel like I've grasped the core concepts of Agile. My answer below might be influenced by how we implemented Agile in our team but I feel we should not focus on adhering to the hardcore definition. I like the idea of "pick what you need" and we have certainly benefitted from this.

Also, you seem to have a misconception that a sprint is part of Agile; a sprint is part of SCRUM.

1. Role

Do you write non-functional stories? Those aren't technical stories to begin with. Technical stories define highly technical requirements. A good way in which technical stories are used is in "Eleven Lessons Learned about Agile Hardware Development".

A non-functional user story could be "As a colorblind person, I want an adapted GUI style so that I can do my color-sensitive work".

2. Feature

How do you avoid relationships between user stories? You don't. If you have no user registration in place, you simply can't develop things that require this functionality.

Is there a technique to break related stories apart so we can have better development parallelism?

Not sure if this hits the nail on its head, but I was thinking that thinking in thin vertical slices might be useful for this.

Stories are the broken apart version of an epic. If you want even more granularity, you can write the classic functional requirements for them; but I feel that since in Agile teams are self-organizing, there should be no more granularity. If more is needed, commnicate with clients or developers.

Breaking relationships also helps better sprint cycles because one story can't stall the whole sprint.

If the sprint is meant to implement user registration, we won't add user stories that depend on user registration to the same sprint. I feel if you want to achieve better development parallelism then you shouldnt focus on developing many user stories in parallel, but rather the set of functional requirements that underpin them, whether they are explicitly specified or not.

3. Benefit

Do you actually write benefits per story or do you rather provide high level goals instead?

The implementation of a user story should be a benefit in itself. As ahoffer pointed out in his answer, the benefit is the "So that.." part of the user story. The epic the user story is part of is the shared goal of all the contained user stories.

Do you write benefits in a way so they can be measurable? Can we do that and is it beneficial?

It depends on the user story. "As a user I want X so that I can do Y faster." and "As a user I want X so that I can do Y in 12 seconds". Suppose that Y is something like saving a file, do we really need to quantifiy that to "12 seconds" instead of "faster"?

4. User stories as a whole

Have you ever defined all user stories as epics?

No, that's not how I feel you should treat user stories. An epic is a large piece of work, and a user stories defines smaller pieces of work within that epic.

What additional metadata do you add to user stories?

The epic they are part of, the sprint that they're part of (if they're the subject of a sprint) and the developers assigned to it. (Again, if the user stories are the subject of a sprint.

I would like to say up front that I am no specialist in Agile development and have been using it with my team for just over a year. However, in this year I feel like I've grasped the core concepts of Agile. My answer below might be influenced by how we implemented Agile in our team but I feel we should not focus on adhering to the hardcore definition. I like the idea of "pick what you need" and we have certainly benefitted from this.

Also, you seem to have a misconception that a sprint is part of Agile; a sprint is part of SCRUM.

1. Role

Do you write non-functional stories? Those aren't technical stories to begin with. Technical stories define highly technical requirements. A good way in which technical stories are used is in "Eleven Lessons Learned about Agile Hardware Development".

A non-functional user story could be "As a colorblind person, I want an adapted GUI style so that I can do my color-sensitive work".

2. Feature

How do you avoid relationships between user stories? You don't. If you have no user registration in place, you simply can't develop things that require this functionality. You can however discuss functionality with the client, make a design or write tests.

Is there a technique to break related stories apart so we can have better development parallelism?

Not sure if this hits the nail on its head, but I was thinking that thinking in thin vertical slices might be useful for this.

Stories are the broken apart version of an epic. If you want even more granularity, you can write the classic functional requirements for them; but I feel that since in Agile teams are self-organizing, there should be no more granularity. If more is needed, commnicate with clients or developers.

Breaking relationships also helps better sprint cycles because one story can't stall the whole sprint.

If the sprint is meant to implement user registration, we won't add user stories that depend on user registration to the same sprint. I feel if you want to achieve better development parallelism then you shouldnt focus on developing many user stories in parallel, but rather the set of functional requirements that underpin them, whether they are explicitly specified or not.

3. Benefit

Do you actually write benefits per story or do you rather provide high level goals instead?

The implementation of a user story should be a benefit in itself. As ahoffer pointed out in his answer, the benefit is the "So that.." part of the user story. The epic the user story is part of is the shared goal of all the contained user stories.

Do you write benefits in a way so they can be measurable? Can we do that and is it beneficial?

It depends on the user story. "As a user I want X so that I can do Y faster." and "As a user I want X so that I can do Y in 12 seconds". Suppose that Y is something like saving a file, do we really need to quantifiy that to "12 seconds" instead of "faster"?

4. User stories as a whole

Have you ever defined all user stories as epics?

No, that's not how I feel you should treat user stories. An epic is a large piece of work, and a user stories defines smaller pieces of work within that epic.

What additional metadata do you add to user stories?

The epic they are part of, the sprint that they're part of (if they're the subject of a sprint) and the developers assigned to it. (Again, if the user stories are the subject of a sprint.

I would like to say up front that I am no specialist in Agile development and have been using it with my team for just over a year. However, in this year I feel like I've grasped the core concepts of Agile. My answer below might be influenced by how we implemented Agile in our team but I feel we should not focus on adhering to the hardcore definition. I like the idea of "pick what you need" and we have certainly benefitted from this.

Also, you seem to have a misconception that a sprint is part of Agile; a sprint is part of SCRUM.

1. Role

Do you write non-functional stories? Those aren't technical stories to begin with. Technical stories define highly technical requirements. A good way in which technical stories are used is in "Eleven Lessons Learned about Agile Hardware Development".

A non-functional user story could be "As a colorblind person, I want an adapted GUI style so that I can do my color-sensitive work".

2. Feature

How do you avoid relationships between user stories? You don't. If you have no user registration in place, you simply can't develop things that require this functionality.

Is there a technique to break related stories apart so we can have better development parallelism?

Not sure if this hits the nail on its head, but I was thinking that thinking in thin vertical slices might be useful for this. Stories are the broken apart version of an epic. If you want even more granularity, you can write the classic functional requirements for them; but I feel that since in Agile teams are self-organizing, there should be no more granularity. If more is needed, commnicate with clients or developers.

Breaking relationships also helps better sprint cycles because one story can't stall the whole sprint.

If the sprint is meant to implement user registration, we won't add user stories that depend on user registration to the same sprint. I feel if you want to achieve better development parallelism then you shouldnt focus on developing many user stories in parallel, but rather the set of functional requirements that underpin them, whether they are explicitly specified or not.

3. Benefit

Do you actually write benefits per story or do you rather provide high level goals instead?

The implementation of a user story should be a benefit in itself. As ahoffer pointed out in his answer, the benefit is the "So that.." part of the user story. The epic the user story is part of is the shared goal of all the contained user stories.

Do you write benefits in a way so they can be measurable? Can we do that and is it beneficial?

It depends on the user story. "As a user I want X so that I can do Y faster." and "As a user I want X so that I can do Y in 12 seconds". Suppose that Y is something like saving a file, do we really need to quantifiy that to "12 seconds" instead of "faster"?

4. User stories as a whole

Have you ever defined all user stories as epics? =

No, that's not how I feel you should treat user stories. An epic is a large piece of work, and a user stories defines smaller pieces of work within that epic.

What additional metadata do you add to user stories?

The epic they are part of, the sprint that they're part of (if they're the subject of a sprint) and the developers assigned to it. (Again, if the user stories are the subject of a sprint.

I would like to say up front that I am no specialist in Agile development and have been using it with my team for just over a year. However, in this year I feel like I've grasped the core concepts of Agile. My answer below might be influenced by how we implemented Agile in our team but I feel we should not focus on adhering to the hardcore definition. I like the idea of "pick what you need" and we have certainly benefitted from this.

Also, you seem to have a misconception that a sprint is part of Agile; a sprint is part of SCRUM.

1. Role

Do you write non-functional stories? Those aren't technical stories to begin with. Technical stories define highly technical requirements. A good way in which technical stories are used is in "Eleven Lessons Learned about Agile Hardware Development".

A non-functional user story could be "As a colorblind person, I want an adapted GUI style so that I can do my color-sensitive work".

2. Feature

How do you avoid relationships between user stories? You don't. If you have no user registration in place, you simply can't develop things that require this functionality.

Is there a technique to break related stories apart so we can have better development parallelism?

Not sure if this hits the nail on its head, but I was thinking that thinking in thin vertical slices might be useful for this. 

Stories are the broken apart version of an epic. If you want even more granularity, you can write the classic functional requirements for them; but I feel that since in Agile teams are self-organizing, there should be no more granularity. If more is needed, commnicate with clients or developers.

Breaking relationships also helps better sprint cycles because one story can't stall the whole sprint.

If the sprint is meant to implement user registration, we won't add user stories that depend on user registration to the same sprint. I feel if you want to achieve better development parallelism then you shouldnt focus on developing many user stories in parallel, but rather the set of functional requirements that underpin them, whether they are explicitly specified or not.

3. Benefit

Do you actually write benefits per story or do you rather provide high level goals instead?

The implementation of a user story should be a benefit in itself. As ahoffer pointed out in his answer, the benefit is the "So that.." part of the user story. The epic the user story is part of is the shared goal of all the contained user stories.

Do you write benefits in a way so they can be measurable? Can we do that and is it beneficial?

It depends on the user story. "As a user I want X so that I can do Y faster." and "As a user I want X so that I can do Y in 12 seconds". Suppose that Y is something like saving a file, do we really need to quantifiy that to "12 seconds" instead of "faster"?

4. User stories as a whole

Have you ever defined all user stories as epics?

No, that's not how I feel you should treat user stories. An epic is a large piece of work, and a user stories defines smaller pieces of work within that epic.

What additional metadata do you add to user stories?

The epic they are part of, the sprint that they're part of (if they're the subject of a sprint) and the developers assigned to it. (Again, if the user stories are the subject of a sprint.