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.

Independent

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.

Negotiable

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.

Valuable

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: