This article looks to discuss ‘Creating Good User Stories in Agile Projects’. It provides an introduction to user story creation while focussing on the role of the Scrum product owner within this process.
Creating Good User Stories
A 59 Seconds Agile Training Video
Creating Good User Stories For Product Owners – Part 2
A 59 Seconds Agile Article
Clearing up technical debt, while a necessary part of software development, does not constitute enough value to warrant a user story. The point of the user story is to deliver value to the stakeholders. Addressing technical debt may improve code performance and make it easier to maintain, but this does not give value to the end user.
By following the user story form that requires a role, a feature, and a reason, the Product Owner can know that this feature will add value. The feature will service some need that a role or user definitely has. Because of this, the team will have improved the product once the user story is finished.
Creating Good User Stories: Estimable
If a user story is concrete enough to get an idea of how much effort it will require to complete, it is estimable. Estimates do not have to be incredibly specific, a general idea in the form of story points is close enough. If a user story is too large to give an estimate, the Product Owner should split it into multiple individual stories. Estimating user stories allows the team to know how much work they can accomplish in a single sprint. Without estimates, user stories may span across multiple sprints, or leave team members without work if they finish very quickly.
Creating Good User Stories: Small
Since Agile consists of short sprints, user stories must be small enough to handle within a sprint. User stories work like building blocks, with each story adding value to the product. With small user stories, the product can evolve over time, and stakeholders receive value quickly and more regularly.
In addition to being functionally small, user stories should be limited in text and detail as well. One or two sentences is plenty of detail for the team to create a working feature. Any more information than just what is necessary slows the entire development process with extra overhead. When explaining the concept for a user story, the idea should be short and simple.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Creating Good User Stories: Testable
When a user story can produce a definite pass or fail criteria, it is testable. Offering pass or fail conditions reduces miscommunication between roles. Developers and testers alike know what is expected of a feature, and clearly see whether it does what it was intended to do. Without this clarity, the team could waste time determining whether a user story is finished when they could be working on more features and adding more value to the product.
A user story should contain all of the work to make a feature work from start to finish. Backend changes must be grouped with their front end behavioral changes. Without a testable piece, a team cannot determine whether the changes have been successfully implemented. Plus, changes without adding features give no value to stakeholders.
As the backbone of Agile Software Development, user stories must be useful to offer value to a product and the team. This responsibility lies with the Product Owner. Whether the Product Owner writes the user stories themselves, or whether they allow other roles to write them, it is imperative that they only allow good user stories into the backlog. If a user story satisfies each of these discussed properties, it should give the team a good idea to work off of and to create a new feature for the product.
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
