User Story Creation - NextensArelB/SwaggerGenerationTool GitHub Wiki

##Objective Break down the Feature into workable work items

##Who

• Quality engineers (QA), Developers (DEV)

##What

When design is signed off, tech and test analysis is completed, the QA and DEV determine the division of the Feature into User Stories and tasks, where each User Story should have a reasonable amount of work.

Steps to follow:

• QA and DEV jointly determine which User Stories need to be created, what the exact content is and which Acceptance Criteria are applicable to each User Story
• Determine per User Story if test automation is applicable and if so which parts
• Create the User Stories inside the Feature
  • an Excel import can be used to standardize the creation of User Stories and underlying tasks
• Add the Acceptance Criteria per User Story
  • Do not repeat AC which are already described in another design (e.g. Figma, XML, Database, Storybook), but only refer to those Criteria, example: the Layout of the page is according to design in Figma (and add Figma link incl version date)
• The dev and test tasks are created on User story level (preferably standardized tasks, so it is clear to whole team what the task is about), this is done after the test and tech analysis

Don't forget to add User Stories for technical aspects that are needed to build a new Feature (infrastructure, resolvers, etc.). Also don't forget to add a User Story for E2E Testing.

What is in a User Story?

1. A link to design (currently Figma)
2. Acceptance Criteria
3. Connected Api Acceptance Criteria

User Stories should have a clear title that ensures that everybody knows what will be delivered when that User Story is "done". If it isn't possible to have a title that everyone understands (due to it being a technical User Story for example), make sure to add an explanation in the description.

For the User Story titles we use '[...]' as a kind of tag in the titles.

1. The first tag explains the general Feature to which it belongs, like [JS] for Jurisprudentie, or [Nieuws] for Nieuws. These tags should not be too many characters, this clutters the title.
2. The second tag explains the specific Feature it relates to, for example [LP] for a landing page or [OP] for an overview page.
3. The third tag explains the kind of work required. We use [Client] for work needed on the frontend, [API] for work needed on the backend and [E2E] for E2E testing.

For example: [JS] [OP] [Client] Add source link behaviour is a User Story adding link behaviour in a source on the Frontend of Jurisprudentie Overview page.

After these tags, a proper title can be added as explained above.

The description of the User Story should, like the Feature, include an actual User Story: As a ... I want ... So I can ...