Volaris - 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 (usually by PO) according to the format outlined at "Development Backlogs → User stories" section.
- Back-end Stories to be written (usually by Dev team) according to the template as outlined below (if applicable) and should contain as many details as possible.
- Bugs to be written according to the 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" .
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>
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.
Preformatted template for pasting into JIRA
*Purpose/Overview:*
*Requirements/Scope:*
# Requirement
# Requirement
*Approach:*
*Acceptance criteria:*
* AC
* AC
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
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:*
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;
5. Estimation in Story Points is added;
6. There are no blockers, dependencies, prerequisites preventing the team from completion of the item; any dependencies must be clearly identified via linked issues (has to be done before, has to be done after, has to be done together with, is blocked by).
7. Story should conform to INVEST requirements (if possible):
Independent
Negotiable
Valuable
Estimatable
Small
Testable
Volaris - Definition of Done
Please note that all items in checklist marked with [M] are mandatory.
Checklist | Feature/User Story | Sprint Demo/Review | Release |
[M] Unit tests are written and are passing. At least 80% code coverage is expected and 100% is preferred for critical code. | Y | ||
[M] Pull request is created following existing templates for mod-kb-ebsco and ui-eholdings in folio.org and contain a .gif of feature implemented where its appropriate | Y | ||
[M] Peer code review is performed and at least one developer from Ebsco and one developer from Spitfire team are requested for code review; code can be merged to master only when build passes and after peer approval | Y | ||
[M] Fix reported code smells, security vulnerabilities, lint errors that are reported by Sonarqube and other tools in CI pipeline before merging code to master | Y | ||
[M] Existing API tests (backend modules) and Integration tests (UI modules) are maintained/implemented/improved and pass | Y | ||
Microservice contract tests(pact) are created and integrated into CI pipeline – future requirement | Y | ||
[M] Any configuration and/or build scripts are updated and tested | Y | ||
[M] Build deployed successfully to snaptshot-stable environment(test, integration etc.) - future requirement | Y | ||
[M] QA is performed and issues resolved - Feature is tested against acceptance criteria - Tests on supported browsers/devices/platforms pass | Y | ||
[M] Feature implemented meets acceptance criteria defined by PO/TL | Y | ||
Regression tests pass – future requirement | Y | ||
| [M] Data migration scripts are implemented for schema changes | Y | ||
[M] Verify that PII stored is encrypted | Y | ||
[M] verify compliance with GDPR – future requirement | Y | ||
[M] Feature OK’ed by UX and complies with: - https://ux.folio.org/docs/guidelines/ - WCAG 2.0 Level AA accessibility compliance | Y | ||
[M] Feature is accepted by PO and QA (if applicable) - Feature is demonstrated to PO - If acceptable, move the story to "In QA" and assign to QA who will verify - Move the story to “in Review” and assign it to PO who will review and move it to Done if acceptable - When story is demonstrated, verified by QA and no comments from PO till end of sprint and story is not moved to Done, team members can close them | Y | ||
[M] Localization is taken care of in application code | Y | ||
[M] No open critical bugs on any user stories | Y | ||
[M] DoD of each user story, included in demo are met | Y | ||
[M] All demoable features are demoed from the same shared environment – For most demos, this will be FOLIO integration environment | Y | ||
[M] Releases are created following: https://dev.folio.org/guidelines/release-procedures/ | Y | ||
[M] Installation and deployment scripts are updated | Y | ||
[M] Performance tests are created and pass – Example: All end user interactions < 2 seconds for 95 percentile or no degradation in response time for existing functionality | Y | ||
[M] All bugs reported by QA, manual testing, UAT, PO etc. are fixed | Y | ||
[M] Release notes are created | Y | ||
[M] User documentation updated (deployment documentation, scripts/packaging etc.) | Y | ||
[M] User documentation is localized | Y |