Agile development uses four clear delivery methods to bring structure to any project: versions, sprints, epics, and user stories

• A version is a set of features and fixes released together as a single update to your product. Assigning issues to versions helps you plan the order in which new features (stories) for your product will be released to your customers. A version can be made up of multiple sprints
• A sprint is a set period of time during which specific work has to be completed and made ready for review
• An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic.
• A user story (represented as an issue in Jira) captures a description of a feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. User stories are broken up into individual tasks that make up the story (represented as sub-tasks in Jira)

• Keep yourself expressing business value
• Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution
• Avoid the appearance of false completeness and clarity
• Get to small enough chunks that invite negotiation and movement in the backlog
• Leave the technical functions to the architect, developers, testers, and so on

The goal is to outline a particular value to the customer that a team can deliver in an iteration using a few short sentences, ideally using non-technical language. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally, in three stages:

• The brief description of the need
• The conversations that happen during backlog grooming and iteration planning to solidify the details
• The tests that confirm the story's satisfactory completion

I – Independent

• Stories are easiest to work with if they are independent. That is, we'd like them to not overlap in concept, and we'd like to be able to schedule and implement them in any order

N – Negotiable

• A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories

V – Valuable

• A story needs to be valuable. We don't care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important. This is especially an issue when splitting stories
• Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we're serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no presentation layer

E – Estimable

• A good story can be estimated. We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. Being estimable is partly a function of being negotiated, as it's hard to estimate a story we don't understand. It is also a function of size: bigger stories are harder to estimate
• Finally, it's a function of the team: what's easy to estimate will vary depending on the team's experience. (Sometimes a team may have to split a story into a (time-boxed) "spike" that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)

• DO focus on a specific user
  • Avoid the generic role of User when writing user stories. User stories are about all of the role who interact with the system or who realize some value or benefit from the system.
• DO provide acceptance criteria
  • The product owner should list as many acceptance criteria as possible in order to clarify the intent of the story. Acceptance criteria will become QA test cases
• DO have conversations
  • update acceptance criteria and user story details based on your conversations

• DON'T go into detailed requirements
• DON'T provide the solution
  • User stories must be focused on the user need and benifit not solution

• Break into groups of 2-3
• Share the features you brought with the group
• Group decides on 1 feature
• As a group write an epic and a few user stories
• Review epic and user stories and dicuss