User Story is one of the most popular form of requirements documentation in Agile projects. Each User Story contains all needed for proper requirement description: who, what and why.
As a <role> I would like to <what> in order to <why>.
As a customer I would like to see available products in order to find product which will meet my needs.
For proper usage of User Stories it is useful to know three acronyms, which I will present in this article.
INVEST
Good User Story should be:
Independent – Story should not be dependent on other Stories or any external work. It is not always possible but that should be a general direction. The more dependencies you have, the less flexible Product Backlog is and more risk you introduce into the development process.
Negotiable – Story should capture generally who, what and why, but at the same time should avoid detailed description. All details should be part of conversation and negotiations between customer and developer. You can say that a proper User Story is composed of three C’s:
- Card – User Story and description;
- Conversation – talks between customer and developer, negotiations;
- Confirmation – tests which will confirm that the feature is ready;
Valuable – Story should bring value to the end customer. Each single one, no exceptions!
Estimable – Story should be clear enough to allow estimation. When a Story is not possible to be estimated you should probably either do a Spike (timeboxed Story which aim is to increase knowledge inside the development team), or just split it (see next acronym).
Small – Story should be doable in one Sprint (Increment).
Testable – Story should be clear and precise enough, to allow testing.
INVEST acronym was created by Bill Wake. Should you desire more information there is an article for each separate letter of acronym – just go here.
SPIDR
When dividing a User Story you can consider various possible split dimensions.
Spike – timeboxed Story focused on gathering more knowledge about technical possibilities or business domain. Most of the times after doing a Spike you will be able to divide the Story using one of other approaches.
Path – divide by paths linked with business processes or decisions. E.g. you can pay by card or by PayPal – two separate ways to go through the process.
Interface – divide by interface, e.g. prepare for Chrome first and then add support for IE and Mozilla. You can also create first version with basic interface and in the next iteration add things like validations, dictionaries and so on.
Data – divide by processed data, start with most critical sub-range of data and add additional sub-ranges in next iteration. Take an example with whether forecast website – start with temperature, then add rain probability, then pressure and so on.
Rules – divide by business rules. Start with implementing feature with no rules or just a basic one and add additional constraints and conditions in next iterations.
It is worth to remember all approaches, as depending on the Story different approaches can bring you benefits. SPIDR acronym was created by Mike Cohn. For more information you can check here.
SMART
User Story should be followed by Acceptance Criteria, which specify in detail what does it mean to accomplish this particular User Story. I like to evaluate Acceptance Criteria using the following conditions:
Specific – should be concrete and precise.
Measurable – should be possible to measure.
Achievable – should be possible to achieved by the team (without a need of external help or trainings).
Relevant – should be valuable for the customer.
Time-bound – should be possible to deliver in one iteration.
Acronym SMART is widely known when setting goals, but I found it very useful when it comes to writing good Acceptance Criteria.