Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

We’re working on a new version of

We’re adding tools to help GSA deliver a digital-first public experience. You can track our progress in our open-source repository.

Writing Effective User Stories

A User Story describes a feature, or requirement, that is to be implemented and is independent of a specific tool (i.e. JIRA, Rally, Trello, etc.). User stories are employed in various Agile frameworks including Scrum, Kanban, and Extreme Programming.

User stories should be written as small, independently, testable increments of the business need, and prioritized by the Product Owner. While Product Owners write functional user stories, the Scrum Team can contribute non-functional / technical stories. However, any non-functional user stories added to the Backlog must also be vetted and prioritized by the Product Owner. Overall, user stories should enable conversation between the Product Owner, Scrum Team, and business group(s).

Writing User Stories

During Sprint Grooming, groups of features / requirements, or Epics, are broken down into user stories by the Product Owner. Then Sprint Planning is used to estimate the level of effort to complete a user story through tasking by the Scrum Team.

The user story is a short, simple description of a feature or function written from the perspective of the end user:

As a [ type of user ], I want [ some goal, function ] so that [ some reason ].

An example:

As a Leasing Specialist, I want the ability to upload an SF-81 document so that I can attach it to my lease file.

When writing a user story, it requires key content:

INVEST: Independent, Negotiable, Valuable, Estimable, Small (sized appropriately), Testable

User story independence is ensured when the delivery increment has been fully decomposed; this allows for the appropriate tasking, estimation, sizing, and testability of the effort. The Product Owner negotiates the prioritization of the functionality with the Scrum Team against user needs, while the value of the user story drives its priority.

Further, testability of the user story is captured in the acceptance criteria; it should denote the “The Who” (user), “The What” (capability), and “The Why” (outcome) of the increment. For additional detail on writing user stories, check out our User Story Examples, or review Defining When a Requirement is Complete on defining acceptance criteria. / Office of the CTO

An official website of the U.S. General Services Administration

Looking for U.S. government information and services?