Creating User Stories For Product Owners
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.
For a user story to be independent, it must address a specific action and contain all parts to fulfill that action. If a user story contains only a small portion of a process, it may depend on other actions to accomplish that goal. In that case, the user story is not independent. Alternatively, a user story may contain numerous actions that could each be an individual user story. These multiple actions should be split out into their own respective user stories.
A good judge of independence for a user story is to examine what a product will look like when that user story is finished. If that feature needs more work before it improves the value of the product, the user story may need more content to be independent. When the user story is finished, if the product has working new functionality, that user story likely satisfies the independence criteria.
A user story is negotiable if nuance and detail are left to the team to figure out. A good user story only hits the highlights, including the most valuable and critical details of a feature. Since most of the details about a feature are up for debate, the team can discuss the best way to implement the feature. During the development process, details about the user story should fall into place, while the team satisfies the criteria that are explicitly stated in the user story.
To be valuable, a user story must contribute some information or idea to a project that improves the product for specific role or duty. Teams may try to create user stories by saying, “It would be nice if the product could [feature].” The problem with this type of thinking is that the suggested feature may not be useful for a particular type of user. The idea sounds nice on paper, but no users of the product actually need it. If the team spends time creating this feature, they have contributed no real value to the product.
User stories must be unique to be valuable. The team could write several different user stories for each individual role that might use the same feature, but the end result is the same as if the team had just written a single user story for that feature. The Product Owner must filter out or combine user stories that serve the same purpose, with only minor differences between them.
<– Continue Reading –>
Our Book Recommendations
We found these books great for finding out more information on Agile Scrum:
Master of Agile – Scrum Product Owner With 59 Seconds Agile (Video Training Course)
Introductory Offer: Free Course
What is this course?
This ‘Master of Agile – Scrum Product Owner With 59 Seconds Agile (Video Training Course)’ provides an in-depth understanding of the Scrum Product Owner roles and responsibilities
You will explore the Agile Scrum project life-cycle, including how an Agile User Story is created, to how we know when it is ‘done’
This course is aimed at those with or without prior knowledge and experience of the Agile values and principles
During this course you will learn the tools needed to succeed as a Scrum Product Owner
What will you learn?
You will gain an in-depth understanding of the Scrum Product Owner roles and responsibilities, and you will be able to
- Fully understand the role of the Scrum Product Owner
- Understand the roles involved in an Agile project
- Create an effective Product Backlog
- Effectively participate in Scrum Meetings such as the Daily Stand-up, Sprint Review and Retrospective
- Identify the roles involves in the Scrum Team
What topics are covered within this course?
You will cover the following topics during this course:
- An Introduction to Agile Project Management (Product Owner)
- The 12 Agile Principles (Product Owner)
- The Declaration of Interdependence (Product Owner)
- Introduction to Scrum (Product Owner)
- Scrum Project Roles (Product Owner)
- The Agile Project Life-cycle (Product Owner)
- Acceptance Criteria and the Prioritised Product Backlog (Product Owner)
- Epics and Personas (Product Owner)
- Sprint Planning (Product Owner)
- User Stories (Product Owner)
- The Daily Scrum (Product Owner)
- The Product Backlog (Product Owner)
- Scrum Charts (Product Owner)
- Review and Retrospective (Product Owner)
- Validating a Sprint (Product Owner)
- Releasing the Product (Product Owner)