The requirements are best defined as user stories. They are described in the language of the customer. The customer's expectations of the product, service or process are described. For example, a user can search the product list via a search mask and gets a result. Technical details and processes are omitted. In a good User Story, the who, what, and why must be clarified. User Story's are described via a template: As a <type of user (customer, user, role); Who>, I want <a goal (function, requirement); What> so that / with it <benefit (reason); Why>. In a User Story, the goal must be clearly communicated. As a user, I want to search for a customer ID so that a customer can be found faster. This representation helps the stack holders to better understand the need of the customer. The User Story is sorted by priority and story point. The priority is the importance and value of a User Story and the story point is the effort to implement a User Story. If User Stories are more extensive, they can be subdivided and assigned to an Epic. If a User Story is even more extensive, a theme is defined.
In Jira, the Epic version can be activated as follows and created with Create Epic.
A User Story can then be assigned to an Epic as follows.
A technical task description might read as: Implement a way to distribute emails to different recipients. Using the language template, it would be translated into a User Story as follows. The user of the app/software for professional purposes, would like to have the possibility to send his emails to different recipients, so that he only has to formulate the email once and can send it directly to further recipients (without repeating this process several times and thus saving work and time (automation);Is optional; depending on the context).
Each User Story is only complete when it meets the quality criteria of the Definition of Done for example:
A User Story must be structured according to the INVEST criteria. Independent. Each User Story must be clearly distinguishable from another User Story. Negotiable. The User Story must be negotiable and adaptable as long as it is in the product backlog. Valuable. User stories must generate added value for the user. Estimable. It must be possible to clearly determine the effort of the User Story during Sprint planning. Small or Sizable or Small. A User Story must be able to be implemented within one Sprint, otherwise it should be defined as Epic. Testable. The User Story must be able to be tested.
The Definition of Ready of a User Story defines the quality criteria for describing the User Story before it can be implemented in the Sprint. The quality criteria to describe the user is industry dependent and Scrum team dependent. The INVEST acronym can be used to define Definition of Ready quality criteria. A User Story is independent of other User Stories, Scrum teams, or other factors. The User Story must be negotiable between development team or product owner. The accomplishment of the User Story must generate added value. The effort required to implement the User Story is estimable. The User Story must have a suitable scope and size for implementation in a Sprint. The User Story must be testable so that the Definition of Done can be fulfilled.
If the User Story appears too complex, user stories can be subdivided. The complex User Story is then the Epic which is assigned to the user stories. An Epic can be a generalization of User Stories, which refer to individual users, for example of operating systems. The Epic is described as a User Story which describes a general user. Each User Story must satisfy the Definition of Done.
A User Story can be created via Create Issue. It is also possible to create not only a Story but also a Task or a Bug.
A User Story can be created via Create Issue.
After the User Story is created, it can be assigned to a Sprint.
Then the Sprint can be started and the Sprint duration as well as the Sprint target can be defined.