<!-- Replace the text between parenthesis by your content -->
# ✏ Start describing your new feature from here
## User story format
(Write your user story here)
-**As** a ‹role›
-**I want** to ‹feature short description›
-**So that** ‹list of benefits›
_If you can’t answer what **‹list of benefits›** this feature **‹feature short description›** brings to end users **‹role›**, then you’re doing something wrong._
## Description
Describe the value and use cases of this feature.
## Acceptance criteria
(Write acceptance criteria here)
- [ ] Should ‹testable condition that should be satisfied›
- [ ] Should ‹testable condition that should be satisfied›
- [ ] …
## Attachment
Add any relevant documents/screenshot/wireframe
## 👇 🧽 Helpers : Delete sections above, it's just here to show you examples 👇 🧽
### US sample format
-**As** a Account Manager
-**I want** a sales report of my products to de sent to my inbox daily
-**So that** I can monitor the sales progress
### Roles sample
* _**User**_ of R2Devops
* _**Contributor**_ of R2Devops
### Acceptance criteria sample
- [ ] The report is received in my inbox daily
- [ ] The report contains name, price, total sales details
- [ ] The report is in csv format
### Explain acceptance criteria scenario-based
- GIVEN that I’m an account manager
- WHEN I open my daily report
- THEN the report shows 3 columns name, price and total sales
### A good user story should be (I-N-V-E-S-T principle)
* _Independent_ (from other user stories, allowing to realize them in any order);
* _Negotiable_ (US are not explicit contracts and should leave space for discussion);
* _Valuable_ (implementation delivers an increment of functionality, observable by and useful to users);
* _Estimable_ (developers should be able to estimate its size relative to other stories);
* _Small_ (implementation fits in one iteration – if it needs many to complete, it is an EPIC);
* _Testable_ (user must be able to check the acceptance criteria)
