Creating User Stories
The user story is a core part of Agile Software Development. Where other methods of software development have functional requirements and technical specifications, Agile has user stories. These user stories serve to explain what the product should be able to do, without specifying details. This gives the team freedom to do things in a way that is efficient and practical while ensuring that stakeholders get the product that they want.
User stories usually consist of one or two sentences explaining who it is for, the desired behavior and the reason for the requirement. The typical form is: “As a [role], I can [feature] so that [reason].” By following this form when writing user stories, the team can cover the who, what, and why about a feature. Writing good user stories helps to ensure that the team creates valuable features for the product.
But who is responsible for writing user stories? The Product Owner is in charge of prioritizing and accepting user stories, but anyone on the team can write stories. If other team members write a user story, the Product Owner can accept or reject them before they are incorporated into the product backlog. If the Product Owner allows bad user stories into the backlog, it wastes time for the team because they do not contribute value to the product. Instead, the Product Owner should only allow user stories into the backlog that are independent, negotiable, valuable, estimable, small, and testable.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: