Landing Page

[SaschaRadojkovic]

Value Proposition

As a user i want to see a list of allergene

so that I have an overview of them

Description

Acceptance Criteria

• [x] The user is able to view a list of allergens

  ​

Tasks

• [x] hardcode a array of objects of 20 allergens with a variable in the project
• [x] display list of allergens
• [x] create an allergene card component

• [x] each allergene is displayed by a card component

  ​

Complexity

... (T-Shirt Sizes S)

[RobinWitt]

I like the overall content and structure of your user story! However it feels like there is a lot of tasks for one story. Maybe you can split up the "list with checkboxes" and the "search bar/function" into two different stories?

[RobinWitt]

Maybe its fine, since you gave it size L. I'll approve it anyway, since we have to get some more experience on the size.

[SaschaRadojkovic]

I like the overall content and structure of your user story! However it feels like there is a lot of tasks for one story. Maybe you can split up the "list with checkboxes" and the "search bar/function" into two different stories?

yes maybe it is to much for one userstory ..we will see and learn ;) and thanks

[NikRoe]

Hey Sascha, I would split this user story up into several smaller user stories.

There is a lot of functionality you mean to implement from the very start and this will lead to a very big user story.

I have a few questions / notes, that might help you with your user story:

What will happen, if I check an entry? This could and should be clarified and depending on what the answer is, it might even be a single user story.

There is a button for the settings (I assume), but no means to enter settings yet. We only want to show elements that serve a purpose already. A button that does nothing should not be displayed even if you intend to have another story at a later point for implementing the button.

I would make a single user story for:

• the general display of the information (are those hardcoded for the moment?)
• deleting an entry
• searching for entries
• the settings button

[SaschaRadojkovic]

Hey Sascha, I would split this user story up into several smaller user stories.

There is a lot of functionality you mean to implement from the very start and this will lead to a very big user story.

I have a few questions / notes, that might help you with your user story:

What will happen, if I check an entry? This could and should be clarified and depending on what the answer is, it might even be a single user story.

There is a button for the settings (I assume), but no means to enter settings yet. We only want to show elements that serve a purpose already. A button that does nothing should not be displayed even if you intend to have another story at a later point for implementing the button.

I would make a single user story for:

• the general display of the information (are those hardcoded for the moment?)
• deleting an entry
• searching for entries
• the settings button

in the first step the checkboxes should just be checked without function. Later they will be added to the filter list of my unwanted additives and allergens.

The page we are on at the moment is the settings page and the landing/startPage. which may be expanded later.

the plan is to filter and map the data from the allergens.json and additives.json imported into the project. the most important allergens i would possibly hard code.

[NikRoe]

I see! Thanks for clarifying the part with the settings page. Then it makes total sense to have that link already present.

I am not really sure how your app will work after implementing this user story, though. If there is no functionality behind a button, a link or checkbox, those elements should not be implemented yet.

Your acceptance criteria should describe what will happen when the user interacts with your app, like:

• when a user checks a checkbox, this and this happens

Moreover, there is a header (most likely a component) that you are showing in your wireframe but aren't mentioning in your user story.

It is totally fine to have some static data at the end of your first user story without any checkboxes.

Edit: Fixed some typos

[NikRoe]

Hey Sascha, this user story is most likely too big and should be split up into smaller ones.

As an idea / suggestion, I would split your user story in those smaller ones:

• US 1: Allergenes are displayed statically in a list with a card component for each allergene
• US 2: You can search for allergenes and add them to the list (a question here would be what in data you are searching / filtering. This needs to become clear from the respective user story)
• US 3: Allergenes can be removed from the list

On a more general note: Try to be specific in your Acceptance Criteria in describing what happens in what case (for instance: What happens, if no entry is found? etc.)

I hope this helps 🤞

[NikRoe]

Hi Sascha,

really nice that you implemented my suggestions to cut the user story a lot shorter!

Only some minor notes:

• You cut out the "Acceptance Criteria" heading ;)

• if you work with a component for your allergenes, please mention that in your tasks like this:

  • display list of allergens
  • create card component
  • each allergene is displayed by a card component

• You should also rephrase your value proposition to something like this:

As a user I want to see a list of allergenes so that I have an overview of them

The value proposition for the first user story is the hardest, but if you apply the above changes, you're good to go with the first US 🥳

[SaschaRadojkovic]

"I have changed the pending things, do I have to post it again on slack? "

[RobinWitt]

Looks good to me!

[NikRoe]

Though you already did so, Sascha, regarding your question: Yes, please post user stories (and at a later point Pull Requests) again in the corresponding channels, if you had to make some adjustments. Excluded from this are small typos etc.

The channels serve as a transparent means of displaying the order in which user stories etc. will be reviewed