User Story Definition and Fields

Updated 2 weeks ago by Estela García

A user story is an element used in Agile Software Development to contain a description of a requirement from an end-user perspective. For further information about Agile frameworks, please, visit our Be Agile with Copado section.

User stories are the primary software development elements with a short, simple and complete description of the user’s needs and contain enough relevant information as to be implemented by the developers during a Sprint (Sprints are described in the following section).

Characteristics of a Good User Story

A good user story is INVEST:

  • Independent (I) - User stories should be self-contained, independent of other user stories.
  • Negotiable (N) - User stories should be allowed for change and rewritten until they start to be implemented in a timebox.
  • Valuable (V) - Each user story should deliver a business value to the user.
  • Estimable (E) -  Each user story should be capable of being estimated to determine its size / effort.
  • Small (S) - User stories should be small enough to fit within a timebox.
  • Testable (T) - A user story needs to provide information that is necessary for testing i.e. to make the development of tests possible.

User Stories are created following the pattern described below:

                        As a <user role>, I want to <goal> so that <reason>.

With this user story description, the user describes the role or type of users, what they want and why.

User stories management is located within CCM application, User Stories tab.

Within this tab, you will be able to list all user story records, create list views and manage user stories as well as list views.

When creating a new user story, a popup window will open to select the User Story record type:

  • Bug: a defect or error found in the product.
  • Investigation: a R&D request.
  • User Story: a feature request.

After choosing one record type and clicking on ‘Next’, the following page will open:

Relevant fields

User Story layout contains a wide collection of fields and related lists. Here, we will describe those fields that will provide value to Change Managers, Scrum Masters or Product Owners when managing User Stories:

  • User Story Reference: User Story identifier created automatically by Copado (not changeable).
  • Project: Project where the User Story will be placed and therefore, it will follow the Deployment Flow related to that Project.
  • Sprint: When the User Story is planned within a Sprint, it can be added here.
  • Epic: If the User Story is part of an Epic, it will be added here.
  • Theme:  If the User Story is part of a Theme, it will be added here. More information about themes here.
  • Parent Epic Title: When adding an Epic for the User Story, the Epic Title will be automatically populated here.
  • Release: If the User Story is part of a product version/release, it must be added here.
  • Priority: Defines a priority for the User Story.
  • Org Credential: The Org Credential where the development was done or it is going to be done.
  • Environment: This field is automatically completed when the Org Credential field is set.
  • View in Git: Link to the feature branch in Git.
  • Owner: This field contains the Owner (Product Owner or any other business stakeholder who created the requirement).
  • Team: This field contains the Team in charge of the User Story.
  • Promote Change: If this checkbox is marked, the User Story will be available for Promotion.
  • Promote and Deploy:  If this checkbox is marked, a promotion and a deployment will be created with this User Story.
  • Status: It defines the current status of the User Story. It is a very useful field to know if the work is already approved, is in progress, is done, is blocked,... or any other status relevant for the organization.
  • Progress: Determines the percentage of the User Story is already completed (available as of v11).
  • Progress Status: Displays a graph with the progress done (available as of v11).
  • Close Date: If the User Story has a due date, it can be added here.
  • Cancellation Reason: Reason of the User Story cancellation, rejection or any other situation we want to have documented.
  • Stop Indexing Metadata: Check this field if you want to stop indexing this User Story contained within a Project which has the “Index Metadata” checkbox marked.
  • Exclude from CBM: If checked, the User Story will not be included in the count of User Stories ahead and behind in Branch Management feature.
  • Backlog Rank: I can set a rank within the Backlog for this User Story, so I can prioritize it when creating or editing it. Another way to change its rank is using the Work Manager panel for your Agile Backlog.

Agile content:

  • Title: Short description of the requirement.
  • As a…: Type of user or role.
  • Want to…: Goal (what I want).
  • So that…: Reason (why I want it).

Usually, when creating a new User Story we will only fill a few fields in, such as Agile Content fields and Status. We will add the rest of the fields later during the lifecycle of the User Story.


  • Acceptance Criteria: Conditions that have to be fulfilled so that the user story is considered as done by everyone. It makes it testable and ensures that the user story can be demoed to users and other stakeholders and released.
  • Acceptance Criteria Status: States if the user story is done or not.

Definition of Done:

  • Documentation Complete: States if the documentation of the User Story is completed or not.
  • Pull Requests Approved: States if Pull Requests of the User Story are approved or not.
  • Manual Tests Passed: States if Manual Tests of the User Story are passed or not.
  • Apex Tests Passed: States if Apex Tests of the User Story are passed or not.

Additional Information:

  • Functional Specifications: Text field available for more detailed functional information.
  • Technical Specifications: Text field available for more detailed technical information.


  • Business Analyst: Product Owner, customer, end-user or any other business stakeholder who can be consulted for further information if needed.
  • Developer: User assigned to the User Story for its implementation.
  • Test Script Owner: User who created the Test Script for that User Story. It could be a QA Team member, a End-User, a business-user or a developer.

User Stories also include a set of related lists that enrich the available information within the User Story detailed page.

How did we do?