Why everyone should know what a good user story looks like?
Whether you are a developer, QA, or a business stakeholder, you should know what a good user story looks like …
What is a user story?
The user story is a term vastly used where the company claims to be using agile methodology. The user story is usually a sentence or two that describes a small piece of functionality that provides business or customer value.
Imagine you are being asked to review the user story or when a user story is refined as a team, how you will provide feedback that the user story has all the required information for you?
In order to provide the input or understand the requirements better, you must know what a good user story looks like.
Scrum co-creator Mike Cohen’s describes a User Story as :
Short, simple descriptions of a feature told from the perspective of the person who desires the new capability.
Who is responsible for writing a user story?
Depending on the product, user stories may be written by various stakeholders including clients, users, managers, or development team members. But it needs to be reviewed by the whole team so that everyone understands it.
What are the characteristics of a good user story?
INVEST is an acronym that was developed originally for agile software projects by Bill Wake. It helps to determine whether the User Story is well understood and ready for the development team to start working on it.
- Independent — the user story should not depend on another user story. So that it can be released on its own .
- Negotiable — the story serves as a basis of discussion between the stakeholders about the method by which a defined goal can be achieved.
- Valuable — the user story should elaborate the needed value to a specific user type — be it user, customer, client or business.
- Estimable — the user story should be enough concrete details for the development team to scope it and work on it.
- Small — the user story should be small enough to fit in an iteration.
- Testable —the story contains enough information to allow it to be tested and to verify that the user story has been completed
But keep in mind, that a user story alone cannot clear all the ambiguities for you.
1) Be it expected code quality
2) Clear guidance on when a story/requirement will be considered done
3) Have we covered all the scenarios?
4) Have we validated and verified the requirement?
5) How many scenarios we are suppose to cover and how many we have actually covered?
6) What does a good deliverable piece of software look like?
7) Is the software ready to ship?
8) Shall we write unit, integration or browser automation test?
9) Does the code needs to have legal or security clearance?
All the above ambiguities can be answered using Acceptance Criteria* and Definition of Done(DoD)**
*For more details on Acceptance Criteria, please read Framework to write User Stories
**For more information on Definition of Done, please read 3 steps to define the Definition Of Done
For any kind of suggestions, feedback or queries, please feel free to comment or contact me on my email address nidasaleem333@gmail.com
