Scrum Methods:  User Story Authorship

Posted on July 10, 2015
by Doug Klugh

Scrum is not just a change in methodology; it is a change in culture.  It is not simply a practice of iterative development; it embraces the principles defined in the Agile Manifesto and places the customer at the center of product development.  For organizations that adhere to Agile practices, their highest priority is to satisfy the customer through early and continuous delivery of valuable software.¹  This is where user stories provide value.  User stories enable project stakeholders (including customers, managers, product owners, team members, etc.) to easily capture ideas for product features without writing extensive documentation.  These ideas then fuel discussions between the customer and development team to elicit functional and non-functional requirements.  Acceptance criteria are also agreed upon so there is a clear definition of what it means when a user story is “done.”

Requirements

Since user stories are closely related to, and often (incorrectly) referred to as, requirements, it is important to understand what is a requirement.  A requirement is a condition or capability to which a system must conform.  This may be a capability needed by a customer or user to solve a problem or achieve an objective, or it may be a capability that must be met or possessed by a system to satisfy a contract, standard, specification, regulation, or other formally imposed document.  Or it may simply be a restriction imposed by a stakeholder.  In any case, requirements are the foundation upon which software is built.

Software requirements can be classified in one of two ways:  functional and non-functional requirements.  Functional requirements define the expected behavior of a system, which can be captured as use cases.  The implementation of functional requirements is described in the system design.  Non-functional requirements define the qualities, or overall characteristics, of a system and may impose constraints on the design or implementation.  These qualities, which are documented in the ISO standard 9126, may include suitability, reliability, security, usability, and portability to name a few.  The implementation of non-functional requirements is described in the system architecture.

User Stories

Before elaborating on user stories, it is important to make one distinction:  User stories are not requirements; they simply represent requirements, providing a starting point for discussion.  Time and time again, software professionals, including Scrum trainers, refer to user stories as requirements.  They are not requirements! Even in Scrum, requirements are captured in requirement documents (which include use cases).  And depending on the amount of compliance regulations imposed by your customer, government agency, or industry, you may need to document a healthy amount of requirements.  For example, United States Department of Defense (DoD) contractors must adhere to an enormous number of regulations, all of which must be documented.  User stories do not alleviate that need in any way, shape, or form.  So please do not refer to user stories as requirements.

So why bother writing user stories?  User stories help to put the customer at the fore-front of product development.  They serve as a catalyst to get the development team talking and interacting with the customer.  Instead of reading (in a requirements document) what the customer thinks he/she wants, user stories initiate discussions so that each side understands what is truly required and reaches a mutual understanding of the issues and risks associated with the desired features.  Since user stories are written in business language and at a high level, they are easily comprehendible by all stakeholders.  They are therefore easy to size, especially when using relative estimation techniques.  And since user stories are relatively small, they can usually be developed within a sprint, which works well for iterative development practices.  User stories also facilitate employing just enough engineering disciplines, just in time to complete development.  Unlike waterfall development, where entire engineering disciplines are completed in stages, Agile methods enable completing just enough, just in time.  And because user stories are generally written by the customer, who is best able to describe expected product behavior, they keep the development team focused on delivering value to the customer.

INVEST

INVEST is a well-known acronym to describe six attributes of well-written user stories. Below are the qualities identified by each letter:

Independent

User stories should avoid introducing dependencies between each other so that they can be developed in any order. This will greatly simplify your planning process. It will also help in prioritizing user stories by focusing on value, cost, and risk without having to consider inter-story dependencies.

Negotiable

User stories are a reminder to have a conversation. In part, this should include negotiating the details of the requirements, along with acceptance criteria. This time should also be spent discussing issues and risks associated with each user story.

Valuable to Customers

Each user story must be valued by the purchaser or user. While users are generally concerned about functionality, as described in functional requirements, purchases are often concerned about software qualities, as described in non-functional requirements. User stories should always be written so that the value it provides to the customer is clear. This will help keep the development team focused on why they’re developing the story and enable the Product Owner to intelligently prioritize the stories. User stories should never include specifics about the user interface as that leads into how the system will be developed. User stories should be restricted to what the system will do or what qualities it must possess. User stories should also not be valued only by developers. If a user story begins with “As a developer…”, that is a clear indication of something which should be written as a task, not a story. While it may explain something that is important to the development team, it is most likely not important to the customer. User stories must always focus on what is valued by the customer.

Estimatable

The development team must be able to estimate the size of the story in order to determine how long it will take to turn the story into working software. To accomplish this, the developers must have domain and technical knowledge of the story. If they don’t, a spike may be needed to investigate unknowns in order to size the story. User stories must also be small enough to estimate. While people are pretty good about estimating small things, they quickly get worse as the things being estimated get bigger.

Small

Accurate estimates are unlikely with large stories. By decomposing user stories into small stories, they are not only easier to estimate, but they are easier to fit into a sprint. A critical practice in Scrum is to ensure that user stories can be developed entirely, from cradle to grave, within a single sprint. Since numerous software engineering disciplines are often needed to completely develop a story, these stories need to be pretty small to complete within such a short window of time (usually two to four weeks). While larger stories can be written as epics, they eventually will need to be decomposed into smaller stories to fit entirely into a sprint.

Testable

User stories must be written as to be testable. In addition to its function and value to the customer, it helps to include acceptance criteria, which lists conditions which must be met before the story can be considered “done.” Meeting these conditions proves successful development. And of course, whenever possible, tests should be automated.

Components of a User Story

User stories are made up of only a few simple parts.  After all, user stories are intended to fit onto a 3” x 5” index card.  With such little space, there isn’t much room for extraneous content.

User stories are identified by a name, which begins with a verb, reflects the function it performs, and is written from the perspective of the user.  The name is often best taken from the <function> section of the story description.

The story description describes the desired functionality.  Although there are variations on the format, one example of a standard user story format is as follows:

As a <user role>, I want to <function> so that <benefit>, unless <exception>

This format is intended to provide just enough detail to initiate a discussion between the customer and the development team.  The user role represents a single user of the system.  However, it may not always represent a human being.  When writing stories for application software, this will usually be the case.  However, when writing stories for system software (such as device drivers), the user role will usually be other systems or components embedded in hardware, firmware, or software.  When determining the user role, ask who or what initiates the functionality of the user story, or who or what benefits from the functionality.  Just be sure that the user role is never a team member.  If you ever want to write a story which begins “As a developer…”, make that a task within a user story.