Short descriptions of a product enhancement (i.e., a product feature) expressed in a specific format. User Stories are simplified requirements
As a
the user role, I wantthe goalso thatthe rationale
- Example 01: As an Open Source Enthusiast, I want to contribute into more repositories so that people get benefited in the process
- Example 02: As a Project Manager, I want to be able to understand my colleagues progress so that I can make efficient reports on success and failures
Coined by Bill Wake in his book Extreme Programming Explored, INVEST is an acronym that defines a simple set of rules used in creating well-formed user stories
[Source: Agile Alliance]
A good story captures the essence, not the details.
by Bill Wake
- Independent: Stories should not be dependent on other stories. No overlapping across one another in terms of functionality ensures flexibility of working regardless of order
- Negotiable: Stories should capture the essence of the requirement and should not represent a contract on how to solve it.
- Valuable: Stories should clearly and perceivably illustrate value to the customer.
- Estimable: Stories should provide just enough information so they can be estimated. However, it's not important to know the exact way that a particular problem will be solved.
- Small: Stories should strive to be concise, to be developed under a few days/weeks.
- Testable: Stories need to be comprehensible to the point where tests can be defined.
- Large user stories are called epics. Decomposing (or splitting) them into individual parts creates user stories.
- There is no point in spending time on breaking down epics that are low priority.
- Immediately after reading the User Story is it obvious what the User Story is about?
- Does each element of the User Story add significant value and therefore avoids duplication or partial duplication of other elements?
- Is it totally 100% free of ‘the how’/the solution?