Overview
User stories represent discrete units of work that are typically assigned to developers by users with administrative permissions in Decisions, often project leads granted such access. These are used to plan, track, and complete development tasks, such as building flows, forms, or tests, and are directly tied to the deployment process. Each story provides a structured container for tracking progress, ensuring changes are validated, and organizing work within broader project timelines.
All user stories reside under Projects, which are identified by a unique prefix (e.g., LOD-0001). This prefix helps keep story identifiers unique across the platform. Stories are organized within sprints, providing a time-boxed view of upcoming or in-progress work, and are associated with builds, which package the changes for testing and deployment.
The purpose of a user story is twofold:
- For admins: To assign work, capture requirements, and track progress.
- For developers: To receive clear instructions, carry out tasks, and ensure changes are associated with deployments.
Requirements
User stories rely on a few foundational elements:
- Projects and Prefixes: Every story belongs to a Project that defines a unique prefix.
- Sprints: Stories can be grouped into Sprints for iterative progress tracking.
- Builds: Completed work is included in builds for validation and deployment across environments.
Attributes
Each user story includes a set of core attributes that help define the scope of work and track its progress through development:
- Title: A brief, clear name for the story.
- Description: A detailed explanation of the work to be done or the problem to be solved.
- Priority: Indicates the importance or urgency of the task (e.g., Urgent, High, Medium, Low).
- Due Date: The target completion date for the story.
- Estimated Time to Completion: An estimate (in hours) for how long the work is expected to take.
- Assigned To: Each story is assigned to a single developer.
- Acceptance Criteria: Describes what must be true for the story to be considered complete.
- Completion Criteria: Clarifies the definition of “done” from a delivery standpoint.
These attributes ensure alignment between the stakeholders assigning the work and the developers executing it.
Creating User Stories
There are two primary methods to create user stories:
- Manual Creation
Stories can be created one at a time through the platform UI:
- Navigate to the Development folder, click on the Sprints section, and select the Sprint where the user story should be added.
- Click Create User Story.
- Fill in the following details:
- Title
- Description
- Priority
- Due Date
- Estimated Time to Completion (in hours)
- Assign To
- Include in Current Deployment (optional checkbox)
- Navigate to the Development folder, click on the Sprints section, and select the Sprint where the user story should be added.
- Bulk Import
Multiple user stories can be created simultaneously using a CSV import wizard:
- Navigate to the Development folder, click on the Sprints section, and select the Sprint where the user story should be added.
- Click "Import User Stories". This will open "Import User Stories" dialog.
- Download the sample file.
- Populate it with story data (Name, description, priority, etc.).
- Upload the file to bulk create user stories and click "Import".
- This will open a dialog where inline edits can be made to the user stories. Once finalized, click "Import" to complete the creation process.
- Navigate to the Development folder, click on the Sprints section, and select the Sprint where the user story should be added.
Once the user stories are created, all the user stories will appear on the sprint dashboard.
Deployment Integration
User stories are created and managed on the Development Server, but are automatically synced with the Deployment Server to ensure traceability and alignment with deployment pipelines.
If the “Include in Current Deployment” checkbox is selected either during story creation or editing and the user story is subsequently checked in to the Deployment Server, a build will be automatically generated on the Deployment Server within the associated Deployment Package.
This automation streamlines deployment planning by ensuring that completed and approved work is automatically packaged for validation, testing, and release.
Developer Workflow
Developers interact with user stories primarily through the Inbox view, which displays a personalized list of stories assigned to them. This enables developers to focus on their tasks across all Projects in one centralized location.
The screenshot below shows the developer Inbox on a development server:
To begin working on a user story:
- Right-click on the assigned user story.
- Select Start Work from the context menu.
- This action opens a dialog to update the status of the user story to In Development:
- Clicking on a user story (e.g., LOD-US-000001) opens the detailed view, showing the current status and workflow stages of a user story.
User Story States
- Not Started: The user story has been created but no work has begun.
- In Development: Development work is actively in progress. Changes made are tracked under this story.
- Pending Review: Work is complete, and the story is awaiting review or approval from the project manager.
- Changes Requested: The reviewer has requested changes. The story is sent back to development for updates.
- On Hold: Work on the story is temporarily paused due to blockers, dependencies, or deprioritization.
- Approved: The user story has passed review and is approved for deployment or further processing.
- Once a story is In Development, additional actions become available:
- Commit Changes
- Mark As Complete
- Add Entity
- Mark As On Hold
- Select Add Entity to link flows, forms, etc., to the story for traceability.
- Once work has started, a user story header appears at the top of the development workspace. This header indicates that any new changes (e.g., flows, forms) are automatically saved under the active story.
- If needed, changes can also be made without associating them with a specific user story. This offers flexibility for quick fixes or exploratory changes that do not require traceability.
- After finishing the work, right-click the user story and select Commit Changes.
- In the Commit Changes dialog:
- Select the user story.
- Check User Story Is Ready For Review if applicable.
- Add a commit message and click Commit.
- This updates the user story status to Pending Review, sending it to the admin (Project Manager).
- The admin can either Request Changes or Approve the story.
- If approved, the story is eligible to be included in the Deployment Package.
Key aspects of the workflow:
- Work is logged under the story header to ensure proper traceability.
- Any work done such as editing flows, creating new entities, or updating configurations is automatically logged under the corresponding user story.
- The platform supports a many-to-many relationship between stories and entities. A single user story can be associated with multiple entities, and each entity can also be linked to multiple user stories.
This structure ensures that all development work is:
- Properly scoped and assigned
- Logged and documented
- Linked to a deployment path
It provides visibility for admins, developers, and QA teams into what has changed, who made the changes, and why supporting smoother deployments and clearer accountability.