User Story and Epic. What is it?

Definition of User Story

The specifications are often a big cause of failure in projects. Bad specifications could lead to misunderstandings about the final product, wrong functionalities, and not required features.

The objective of “User stories” is to respond quickly and with less cost to modifications of requirements (new user needs for example).

With agile methodologies, the US is written to share the vision of developers/testers/project leaders instead of continually reviewing during the redaction phases.
We find this sharing also in the V cycle through the very formal notion of requirements reviews after this one is drafted (less + but very motionless process — no live modification).
The “ user stories “ describe the features that will be useful. The “ user stories “ consist of three aspects ( principle of 3C) :

• Card : Support describing the story
• Requirement ( description)
• Priority
• Planning development/ testing
• Acceptance criteria
• Conversation : Discussion on “ user story “ that add the details ( Tester/PO/Devs ) . This phase begins during the release planning phase and will continue when the User Story will be planned ( mind-mapping / brainstorming)
• Confirmation: Tests that convey and document details and will be used to determine when a “ user story “ is ready to test. These functional/non-functional test will be demoed and followed over time to meet the US and then considered “ Done”
  [ Mike Cohn : User Stories Applied . 2009] [ REQB® Certified Professional for Requirements Engineering Foundation Level ]

Method Invest

What are the characteristics of a good user story? Invest method is a good answer

• I — Independent (Independent of other User Story at release)
• N — Negotiable (Negotiable initially, rather than a firm commitment)
• V — Valuable (Having some Value )
• E — Estimable (Estimable regarding complexity)
• S — Small (Enough Small)
• T — Testable (what we verify by writing a Test)

More in detail

Independent
A User Story must be independent. It should be possible to plan any user story and implement the system in the order you want . This independence also allows testing in removing failed stories of the release.

Negotiable… and Negotiated
A User Story should initially contain no technical element stifling the story will be limited to the essential in defining the release (macro costing). These elements will be added later during exchanges between testers/developers and the writer of the story.

Valuable
A User Story must have a value for the end user.
Example: the code of factorisation is not something relevant from a user perspective. When major changes, it often happens that the development team decides to completely take the lead on technical tasks (of the entire project) instead of focusing only on what is required by the user. It is better to deliver a part of the project but regularly as falling behind on technical tasks affecting the final user (vertical project)

Estimable
A User Story must be evaluated (complexity). To answer this, the acceptance criteria must be clear and understood by all the team. Moreover the User Story should not be too big (1 User Story shouldn’t define a whole project — role of a Epic)

Small
A User Story should not exceed a few man/days. Otherwise, it should be separated in several stories then original story becomes an Epic.

Testable
A User Story is testable. We need the explicit description and criteria, it to be relevant enough to leave no ambiguity in testing. This is one of the most important criteria of a story.

Definition of EPIC

An Epic corresponds to a macro functionality of the system to develop. It includes therefore a set of User Stories that will be linked to the Epic .

An Epic is created from the very beginning of a project.
At this time the functionality is not detailed nor prioritised.
The feature will be specified gradually and the Epic completed with addition/deletion of User Story. The development of EPIC will cover several versions (or sprints) .