Epic, features, user story

They don't even have to be written; a user story is a placeholder for a conversation about a potential requirement.

Agile practice is founded on collaboration and emergence. My advice is to provide enough so the necessary conversations actually happen and take it from there.

Thank you Ian for your reply. 

As a newbie to agile, I was told that I have to follow the following hierachy : Epic > Feature > User Story or Epic > User story (depending on the size of the project).  So I am kind of confused.

What about the acceptance criteria in user story, are they mandatory or not ? And if I want to write them, do I have to follow the strucutre "given-when-then" ? 

Thanks 

If you intend to follow the scrum framework, then you will realise after reviewing the scrum guide that there is no mention of user stories in it, which means that scrum neither dictates what techniques you can use with its framework nor how to use them. 

Concerning acceptance criteria, scrum provides a commitment to the increment(s) that get(s) created during each sprint called the Definition of Done (DoD). 

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

I have to write business requirements with the agile methodology

Which "agile methodology" would that be?  It isn't Scrum because it is a framework. If you could tell us what methodology you are expected to use, we might be able to give you some better answers.  But until then, Let me tell you a little story about User Stories.

User Stories are an artifact of eXtreme Programming.  Here is what extremeprogramming.org says about User Stories (http://www.extremeprogramming.org/rules/userstories.html) 

 

User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

 

One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.

Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in "ideal development time". This ideal development time is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do. Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level, combine some stories. About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning.

 

Another difference between stories and a requirements document is a focus on user needs. You should try to avoid details of specific technology, data base layout, and algorithms. You should try to keep stories focused on user needs and benefits as opposed to specifying GUI layouts. 

Notice that there is nothing mentioned about a specific format or acceptance criteria.  It is an plain language description of a problem the users would like to have addressed. 

The "Story Format" of

As a <entity> I want to be able to <do something> so that I can <value statement>.

• AC1
• AC2
• AC3

came later as people wanted to add a process to the use, much like a lot of agile has been impacted. Same can be said for Epics, Features, etc.  As far as I know eXtreme Programming is the only agile practice that advocated the user of User Stories but the format/content was different than what most Agile practices try to use today.  Notice that I use "Agile" and "agile".  They are different.  "Agile" is commercialized tools, practices, and rules that are claimed to have come for the Manifesto for Agile Software Development.   "agile" is the empirical based set of values and principles that are actually stated in the Manifesto for Agile Software Development. 



My advice to you is to quit worrying about a process or set of rules and start doing work that helps. Start small, inspect the value being derived, adjust as needed. 

The language you are using comes from tools, not frameworks.

Scrum would refer to them all as Product Backlog Items (PBI's) of varying levels of vagueness.

If the Initiative is fine grained, it doesn't need Epics: you're probably doing something like improving the value of an existing product in a small-ish way (up to say 6 sprints).

Epics give "arcs of activity." That's all. So you may have a "make it usable" as your first epic, and "make it mobile" as your second, then "beyond the MVP" as your third (by which point, you may have defined some new Epics). Every iteration is workable - the Epics put the Iterations between bookmarks describing "what did this set of sprints do?".

If your team don't have history of using these, less is best. Even in MS Devops, Epics and Features are not mandatory - they support building reports your non scrum team members may have an expectation of seeing.

To put it another way: Epics and Features are tools to help you build narrative when you communicate. If they don't help that, don't use them.

For developers, are User Stories with Acceptance Criterias detailed enough for them to do their work, or do they need more detailed documentation? If yes, what type of documentation do you produce? Who writes it, the PO or the tech lead?

For developers, are User Stories with Acceptance Criterias detailed enough for them to do their work, or do they need more detailed documentation?

Ask your developers that question.  If the documentation is for them they should be the ones to tell you if there is enough or not.

 If yes, what type of documentation do you produce? 

As a Scrum Master I do not produce any documentation.  As a Product Owner I produce documentation that effectively communicates the problem statement to the Developers so that they can create a technical solution. As a Developer I provide documentation that will allow end users and stakeholders to understand and use the technical solution.  A Developer will also provide whatever documentation is needed in order to maintain the product should staffing change. 

Who writes it, the PO or the tech lead?

First I will point out that tech lead is not a Scrum Role.  But reality often involves someone with that title as part of a Developer team.  



Who writes documentation depends on who has the knowledge to document.  However, who ever does end up writing it is not writing out instructions.  They are providing information that will be useful in identifying and creating a solution to the problem at hand. 

The Manifesto for Agile Software Development states this value

Working software over comprehensive documentation

Notice that it doesn't say there should not be any documentation.  Document what is needed to enable working software to exist.