“If a user story includes an implementation detail then it isn’t a user story” — Tweet by Steve Bishop
User Stories should be: User-Focused, Vertically Sliced, Describe Value, INVEST (Acronym for): Independent, Negotiable, Value, Estimable( Complexity not Time), Small Enough (Testable story), Testable.
“… understable to customers and developers”- Kent Beck
Half a dozen in one iteration.
Where to start?
Persona (Semi-fictitious) representations of your target users.
User Story Format: As a (persona) I want to (Action) So I can (Value) [Who?, What? and Why?]
It shouldn’t have any implementation details (It’s not about the developer, it's all about users). Example: Create Response Class For JSON With the UserController. This example is a poor user story.
A good user story: As (a) Simon, I want to submit my credentials, So that I can access secure parts of the system.
More examples: As a Charlie, I want to save my credit card information, So that I do not have to re-enter it later. As a Quinton, I want to hear the headings with my e-reader So that I know the context of each paragraph.
Things to Avoid
User roles and job titles are NOT a persona. Avoid (AND/OR) may be another story is emerging out of it. Avoid ambiguous language.
Vertical Slicing of User Stories
Story cares only about one persona. Has only one specific action the user can take. Story has multiple layers/architecture but not described, it just cares about thin line in the architecture.
Write a test following AAA (Arrange, Act, Assert) OR Gherkin (Given, When, Then).
Stories should be prioritised by their value to the user. Whoever is ready takes on the next in the priority queue (no matter how experienced, even its beginner). Preferably a PAIR.
“Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.”- Atlassian
Story should be pointed according to complexity, unknowns and communications. NOT TIME.