Estimating User Stories For Product Owners
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.
Estimating the User Stories
When the user stories have met the team’s Definition of Ready and have been approved by the Product Owner, they still need to be estimated before the team commits to actually working on them. The typical process of estimating user stories during a meeting would be as follows:
● Listing the user stories in scope (these will be listed in priority order according to their value)
● Picking a user story to discuss on (the most valuable user stories will be selected to be discussed)
● Clarifying user story and its acceptance criteria
● Estimating and voting on the user story size
● Re-defining, negotiating and re-voting on the user story, as needed
● Agreeing and finalizing the user story size
Another guideline for Product Owners to know when they can approve a user story is to check if it follows the INVEST mnemonic: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Putting 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.
Estimating the User Stories
When the user stories have met the team’s Definition of Ready or have been approved by the Product Owner, they still need to be estimated before the team commits to actually working on them. Agile estimation techniques are designed to be quickly done and avert from accuracy on purpose. This is because estimates are simply estimates, and are just guides to know how user stories compare to one another in terms of relative complexity.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
The typical process of estimating user stories during a meeting would be as follows:
● Listing the user stories in scope
● Picking a user story to discuss on
● Clarifying user story and its acceptance criteria
● Estimating and voting on the user story size
● Re-defining, negotiating and re-voting on the user story, as needed
● Agreeing and finalizing the user story size
Unless the Product Owner will also be taking part in development activities, they are only going to be there to clarify on the user story and not to participate in actually estimating it.