Relevant Fields on a User Story

Updated 3 weeks ago by Copado Solutions

A user story layout contains a wide collection of fields and related lists. Here we will describe these fields that will provide value to Change Managers, Scrum Masters or Product Owners when managing user stories:

Information

Fields tied to Copado's functionality:

  • Title: Short description of the requirement of the user story.
  • User Story Reference: User story identifier created automatically (not changeable).
  • Project: Project linked to the user story. When the user story gets deployed, the destination org is defined by the pipeline linked to the project.
  • Release: If the user story is part of a product version/release, it must be added here.
  • Org Credential: The org credential of the org where the changes included in the user story have been made.
  • Environment: This value is automatically added by Copado based on the selected org credential.
  • Ready to Promote: If this checkbox is selected, the user story will be available for promotion.
  • Promote and Deploy:  If this checkbox is selected, a promotion and a deployment will be created for this user story.
  • Base Branch: Git branch from where the feature branch originates. By default, it is the main branch of the pipeline or the base branch of the release linked to the user story. This value is updated when committing changes on the user story.
  • Stop Indexing Metadata:  If the user story is linked to a project that has the Index Metadata checkbox enabled, the metadata components committed on the user story will be tracked to see if there are any potential conflicts. If you enable the Stop Indexing Metadata checkbox, the metadata on the user story will not be indexed.
  • Exclude from CBM: If checked, the user story will not be included in the count of user stories ahead and behind.
  • Git Merge Status: The Git merge status of the latest pull request between the feature branch and the destination branch. This value is provided by the Git repository. If there is no value, the Git repository did not provide one.
  • Apex Code Coverage: Coverage of the Apex classes added or committed in the user story.
  • Last Validation Promotion: Promotion that contains the most recent validation deployment.
  • Last Promotion Date: This field is populated when the status of the promotion is set to Completed, that is, if the deployment is completed successfully.
  • Last Validation Deployment: Most recent validation deployment of the user story.
  • Last Validation Status: Status of the latest validation deployment of the user story.
  • Last Commit Date: This field is autopopulated by Copado, when you commit metadata on a user story, with the date and time of the most recent commit.

Fields not tied to Copado's functionality:

  • Record Type: There are different record types you can choose from when creating a user story: Bug, Investigation and User Story. This field will be autopopulated with the chosen record type.
  • View in Git: Link to the feature branch in Git.
  • Sprint: If the user story is planned within a sprint, you can add the sprint here.
  • Status: It defines the current status of the user story. The options include the following: Draft, Backlog, Backburner, Awaiting Approval, Approved, Rejected, In Progress, Ready for testing, Completed and Cancelled.
  • Team: This field contains the team in charge of the user story.
  • Epic: An epic is a large user story that awaits decomposition into smaller stories prior to implementation. If the user story is part of an epic, you can add the epic here.
  • Theme: A theme is a group of user stories which contribute to a common goal. It is the highest level in the user story hierarchy. If the user story is part of a theme, you can add it here.
  • Priority: Numeric value that determines which user stories are more urgent. The lower the number the higher the priority
  • Backlog Rank: You can set a rank within the backlog for a user story so that you can prioritize it when creating or editing it. Another way to change the rank is by using the Work Manager panel for your agile backlog.
  • Parent Epic Title: When adding an epic to a user story, the title of the epic will be automatically populated here.
  • Story Points:  A story point is a unit of effort required to complete a task. In this field you can indicate how long it will take you to complete the task defined in the user story.
  • Owner: This field includes the name of the owner (the product owner or any other business stakeholder who created the requirement).
  • Close Date: If the user story has a due date, it can be added here.
  • Cancellation Reason: If a user story is cancelled, use this field to add the reason why it has been cancelled or rejected.
  • Progress: Determines the percentage of the user story that is already completed.
  • Progress Status: Displays a graph with the progress done.

Agile Content

  • As a…: Type of user or role. Persona for whom you are creating the user story
  • Want to…: Goal (what the persona specified in the previous field wants to achieve).
  • So that…: Reason (what the benefit of the feature requested is for the persona).

Usually, when creating a new user story we will only fill in a few fields, such as those in the Agile content section and the Status field. We will add the rest of the fields later during the lifecycle of the user story.

Definition of Done

  • Documentation Complete: It indicates whether the documentation of the user story is completed or not.
  • Pull Requests Approved: It indicates whether the user story's pull requests are approved or not.
  • Manual Tests Passed: It indicates whether the user story's manual tests have passed or not.
  • Apex Tests Passed: It indicates whether the user story's Apex tests have passed or not.

Acceptance

  • 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: It indicates whether the user story is done or not.

Additional Information

  • Functional Specifications: Add relevant information about how the feature you are building or fixing as part of the user story should work and what it should look like.
  • Technical Specifications: Provide the parameters for what you are building as part of the user story and details about how you are going to implement it.

Resourcing

  • 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, an 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 details page.


How did we do?