This article looks to discuss ‘Agile Story Creation in Scrum Projects’. It provides an introduction to the user story template, and discusses the INVEST criteria for Agile Story Creation.
Agile Story Creation in Scrum Projects
A 59 Seconds Agile Training Video
Agile Story Creation in Scrum Projects For Product Owners
A 59 Seconds Agile Article
The user story is a core part of Agile Software Development. Where other approaches 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. It also ensures that stakeholders get the product that they want.
Agile Story Creation in Scrum Projects: User Story Template
User stories usually consist of one or two sentences explaining who it is for. These two sentences also explain the desired behaviour 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. This is 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.
Agile Story Creation in Scrum Projects: 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.
Agile Story Creation in Scrum Projects: 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.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Agile Story Creation in Scrum Projects: 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.
Prev <— Continue Reading —> Next
The Agile User Stories and Tasks
A 59 Seconds Agile Video Animation
Prev <— Continue Reading —> Next
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Prev <— Continue Reading —> Next
The Agile Frameworks
A 59 Seconds Agile Infographic
