What is involved in Generating User Stories and what role do the developers play in creating the user stories? What is a User Story and what do user stories involve?
Creating Agile User Stories
A 59 Seconds Agile Video Animation
Creating User Stories for Developers
A 59 Seconds Agile Article
User stories are a core part of Agile software development and involve all of the roles of a Scrum team in some way. Developers have a unique responsibility in creating user stories.
Generating User Stories: What is a User Story?
A user story is a function or feature of a product. It is the smallest piece of a product that describes a behaviour. They are simple actions that an average user might need to do in order to use the software. User stories are completely functional. They do not explore technical or system requirements or details at all. Every user story is focused on giving the user the ability to do something. How the system accomplishes these tasks is handled after the user stories are finished.
What Does a User Story Include?
Good user stories follow a general format. “As a <user>, I want <goal> so that <reason>.” This format allows the scrum team to create a user story that is neither too general, nor too specific. With simple answers, the format should describe a unique function that deserves its own user story.
Generating User Stories: Independence
User stories should be independent and stand on their own. Each user story describes a bite-sized feature that is distinct from other system behaviours. One large feature can have several different user stories. Each part that can accomplish a goal should have its own user story to mark it distinct from other parts of the feature. Developers often have to write code for individual parts of a feature. It is better to have user stories for each of the individual pieces so that developers do not have to write an entire large feature in one sprint.
Unlike traditional development, user stories of Agile are negotiable. Most functional specifications in waterfall development are set in stone. Once an organization clears a spec, the product must match that spec to the letter. Changes often require several official documents and stepping through layers of red tape. With Scrum, user stories remain negotiable even until development is finished. If a user story is deemed unnecessary, it can be scrapped or reworked into something more useful. Some user stories may describe larger features that would be difficult for developers to complete in a single sprint. In these cases, the team may split the user story into multiple smaller user stories.
Generating User Stories: Value
Only user stories that offer value should be created. Creating user stories give concrete goals and targets. Since user stories do not describe technical details, they can focus on product behavior. This allows teams to break features down and developers to work on them bit by bit. However, user stories that do not contribute to the overall worth of the product should be left out.
Small and Estimable
The best user stories are small and estimable. Features that are too large become vague and difficult to give work estimates on. By breaking these features down into smaller pieces, each individual piece is small enough to give an estimate of how many story points they will require. Where traditional development estimates tasks by hours, Agile gives story points. Story points do not indicate a definite amount of time but refer to general effort. User stories with more story points will require more effort than user stories with fewer story points. Assigning story points to a user story gives an indication of how large and complex that feature is. However, the user story should still be small enough that developers can finish it within a sprint.
Generating User Stories: Testable
User stories should be testable. Software development occasionally has a hard time determining whether something works. Changes such as adding new fields and other additions may not be directly testable. Several of these changes may be required for a new feature to work as intended. In these cases, the user story should refer to the functional changes that can be confirmed working. Several tasks in a user story can cover changes that will not affect functionality, but the user story itself should include some feature change that can be tested. A developers work may not always be testable, but these necessary changes should be grouped into a user story that is.
Prev <— Continue Reading —> Next
Learn More: Writing Agile User Stories
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
Learn More: Writing Agile User Stories
Writing Agile User Stories
A 59 Seconds Agile Infographic
Prev <— Continue Reading —> Next
Learn More: Writing Agile User Stories
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: