Курнат Андрей
172 lines
3.9 KiB
Markdown
172 lines
3.9 KiB
Markdown
---
|
||
name: User story
|
||
about: Converts your idea into an actionable format ready for sprint implementation.
|
||
title: ''
|
||
labels: Type:Story
|
||
assignees: ''
|
||
|
||
---
|
||
|
||
# Description
|
||
|
||
## User Stories
|
||
|
||
- ***As a ..., I want to ... so that ... (please stick to who, what, why)***
|
||
|
||
## Value
|
||
-
|
||
|
||
## Acceptance Criteria
|
||
-
|
||
|
||
## Definition of ready
|
||
- [ ] Everybody needs to understand the value written in the user story
|
||
- [ ] Acceptance criteria have to be defined
|
||
- [ ] All dependencies of the user story need to be identified
|
||
- [ ] Feature should be seen from an end user perspective
|
||
- [ ] Story has to be estimated
|
||
- [ ] Story points need to be less than 20
|
||
|
||
## Definition of done
|
||
- Functional requirements
|
||
- [ ] Functionality described in the user story works
|
||
- [ ] Acceptance criteria are fulfilled
|
||
- Quality
|
||
- [ ] Code review happened
|
||
- [ ] CI is green (that includes new and existing automated tests)
|
||
- [ ] Critical code received unit tests by the developer
|
||
- Non-functional requirements
|
||
- [ ] No sonar cloud issues
|
||
- Configuration changes
|
||
- [ ] The next branch of the OpenCloud charts is compatible
|
||
|
||
|
||
<details>
|
||
|
||
<summary>Writing Tips</summary>
|
||
|
||
## User Story
|
||
INVEST Criteria for User Stories
|
||
|
||
- **Independent**
|
||
Should be self-contained in a way that allows being released **without depending on one another**.
|
||
|
||
- **Negotiable**
|
||
Only **capture the essence** of the user's need, leaving room for conversation. A user story should not be written like a contract.
|
||
|
||
- **Valuable**
|
||
Delivers value to the end user.
|
||
|
||
- **Estimable**
|
||
User stories must be estimated so they can be properly prioritized and fit into sprints.
|
||
|
||
- **Small**
|
||
A user story is a small chunk of work that allows it to be completed in a short period of time.
|
||
|
||
- **Testable**
|
||
A user story has to be confirmed via pre-written acceptance criteria.
|
||
|
||
## Value
|
||
Examples:
|
||
- Save time
|
||
- Reduce risk
|
||
- Make it accessible for anyone
|
||
|
||
## Acceptance Criteria
|
||
|
||
### What Acceptance Criteria are for
|
||
Acceptance Criteria answer one question only:
|
||
|
||
**How do we know this story is done?**
|
||
|
||
Not how it is implemented. Not what might be nice. Not future hypotheticals.
|
||
|
||
|
||
#### Tie every AC to user value
|
||
Each criterion must protect or enable the user benefit.
|
||
|
||
**Bad**
|
||
- API returns 200 OK
|
||
|
||
**Good**
|
||
- User sees a confirmation that the action succeeded
|
||
|
||
If the user would not notice a failure, question why the AC exists.
|
||
|
||
#### Use observable outcomes
|
||
ACs must be verifiable by anyone, not just engineers.
|
||
|
||
**Bad**
|
||
- System processes data efficiently
|
||
|
||
**Good**
|
||
- Results are shown within 2 seconds after submission
|
||
|
||
If you cannot test it without reading code, it is trash.
|
||
|
||
#### Write from the user’s perspective
|
||
Describe what the user can do or see, not internal behavior.
|
||
|
||
**Bad**
|
||
- Data is stored in the new table
|
||
|
||
**Good**
|
||
- User can see previously saved entries after reload
|
||
|
||
#### Keep ACs binary
|
||
Each AC should be clearly pass or fail.
|
||
|
||
**Bad**
|
||
- Works well on mobile
|
||
|
||
**Good**
|
||
- User can complete the flow on a mobile device without horizontal scrolling
|
||
|
||
If there is room for interpretation, it will be abused.
|
||
|
||
#### Cover the happy path first
|
||
Do not drown the story in edge cases.
|
||
|
||
Start with:
|
||
- Core flow
|
||
- Primary user goal
|
||
|
||
Add edge cases only if they:
|
||
- Prevent real harm
|
||
- Block release
|
||
- Create user-visible failure
|
||
|
||
### Avoid solutioning
|
||
ACs define what, not how.
|
||
|
||
**Bad**
|
||
- Button is implemented using component X
|
||
|
||
**Good**
|
||
- User can submit the form using a visible primary action
|
||
|
||
If you lock implementation, you kill collaboration.
|
||
|
||
#### Use Given / When / Then where helpful
|
||
Optional, but useful for clarity.
|
||
|
||
**Example**
|
||
- **Given** the user is logged in
|
||
- **When** they submit the form
|
||
- **Then** they see a success message and the data is saved
|
||
|
||
If it adds noise, skip it.
|
||
|
||
|
||
### Litmus test
|
||
A good set of ACs allows:
|
||
- A developer to build it
|
||
- A tester to verify it
|
||
- A product manager to accept or reject it
|
||
|
||
Without further clarification.
|
||
|
||
If not, rewrite.
|
||
|
||
</details>
|