Thunderjet - Definition of Ready

User Story/Bug/Task can be added to Sprint only if it conforms to the following criteria of Definition of Ready:

1. Requirements are clearly expressed by PO or any other reporter

Note:

Front -end User Stories to be written according to the format outlined at "Development Backlogs → User stories" section.
Back-end Stories should follow the template as outlined below (if applicable) and contain as many details as possible.
Bugs to be written according to the template.

Front-end User Story Template

Purpose: Story context for casual viewers. What is this story supposed to cover? If it's just an initial iteration of a larger feature, make that clear here.

User story statement(s): The user story statement is optional and you'll notice that many of our stories don't contain them. This is because, between the purpose and the scenarios, there is usually more than enough information to go on. That said, including a user story statement is best practice and if you have them please include them. They will take the format: As a < type of user >, I want < some goal > so that < some reason >

Scenarios: On FOLIO, acceptance criteria are written as scenarios using the "gherkin syntax" (given, when, then)

Attachments/links: Whenever possible, a UX mockup should be attached or linked to the user story. If there are elements of the mockup that are out of scope for the story (for example, because the technical prerequisites are not in place), then they should be noted as "out of scope for this story" .

Link User Story to the related Back-end Story (if any) and other related stories to identify blockers or development order.

Link Story to the related UXPROD feature.

Set the status to "In refinement"

Preformatted template for pasting into JIRA

*Purpose:*

*User story statement(s):*

As a < type of user >,

I want < some goal >

so that < some reason >

*Scenarios:*

# Scenario:

* Given <preconditions>

* When <actions>

* Then <results>

Back-end Story Template

Purpose/Overview: High-level description of problem.

Requirements/Scope: Requirements to be turned into working product.

Approach: Approach to be followed while development (if already discussed and known).

Acceptance Criteria: Acceptance criteria to assess whether the development of story was done in a proper way and requirements are met.

Attachments/links: Any available links to useful documentation, schemas, etc.

Link Story to the related Front-end User Story (if any) and other related stories to identify blockers or development order.

Link Story to the related UXPROD feature.

Set the status to "In refinement"

Preformatted template for pasting into JIRA

*Purpose/Overview:*

*Requirements/Scope:*

# Requirement

# Requirement

*Approach:*

*Acceptance criteria:*

* AC

* AC

Bug Template

Overview: Optional high-level description of problem

Steps to Reproduce:

Log into some FOLIO environment as User X
Click this
Select that
etc.

Expected Results: What I expected to see happen

Actual Results: What actually happened

Additional Information: Anything else I noticed or tested that might be relevant to this issue

Interested Parties: Notify relevant people of this bug by @-mentioning them (type @ then search for their name).

Link But to the related UXPROD feature (if possible).

Fill in RCA field

Preformatted template for pasting into JIRA

*Overview:*

*Steps to Reproduce:*

# Log into some FOLIO environment as User X

# Click this

*Expected Results:*

*Actual Results:*

*Additional Information:*

*Interested parties:*

2. Backlog Item must be linked to a corresponding UXPROD feature.

3. Backlog item is reviewed/groomed and well understood by dev team;

4. Acceptance criteria are clearly defined and confirmed by PO and dev team;

Note: In case there is a need to update acceptance criteria based on grooming activities or some additional investigation:

it must be explicitly communicated to the team and PO (either while some meetings or in the comments to a backlog item;
PO is accountable for the backlog and is supposed to introduce updates into acceptance criteria or confirm that it cam be done by some team-member on behalf of PO;
Estimation of updated backlog item must be updated if necessary;

5. Estimation in Story Points is added;

6. There are no blockers, dependencies, prerequisites preventing the team from completion of the story/bug (if there are any - they must be clearly indicated and story/bug must be moved to Blocked status);

7. After story was groomed set the status to Open and add labels fe-approved/be-approved.

8. Story should conform to INVEST requirements (if possible):

- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable