Estimating User Stories
User stories can come from many places: Sprint Reviews, Sprint Retrospectives, observations, interviews, or even water-cooler conversations. While the Product Owner owns the Product Backlog, anyone can contribute and create user stories. The Product Owner needs to ensure that whatever feature is being developed, is of the highest value and user stories have been created for the feature.
Before the Product Owner can approve a user story, they must first ensure that the user story is well-defined with clear values. User stories should be written such that is clear who the feature is for, what the feature should do, and why the feature is required. A typical user story is written as follows:
“As a <type of user>, I want to <state action here> so that <state value here>.”
Once the user story has been defined, the Product Owner should discuss the acceptance criteria with the team. Clarifying what the user story needs to achieve and what value it will add to the product and for the user.
A guideline that the Product Owners can use to approve a user story is to check if it follows the INVEST mnemonic: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Validating user stories against these criteria can help resolve questions such as whether a user story is too big or if the user story is feasible.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: