Skip to main content

Managing Stories and Backlog Items

Stories and backlog items in Digital.ai Agility include concepts, operations, and best practices for effective product planning.

Who manages stories and backlog items: Product owners define, prioritize, and refine stories to maximize business value. Team members create tasks, update progress, and close stories as work completes. Scrum masters facilitate backlog grooming and coordinate story management across team members. Project admins configure story workflows, templates, and access controls.

Permission requirement: Viewing stories requires basic project member access. Creating and editing stories typically requires Team Member role or higher. Deleting stories requires elevated permissions (typically Project Admin role). Moving stories between projects requires edit permissions in both source and destination projects. Specific permissions vary based on your organization's role configuration.

note

Stories are also called Backlog Items. These terms are used interchangeably throughout Digital.ai Agility.

What are Stories and Backlog Items​

Stories (also called Backlog Items) are the primary Agile planning and tracking assets that are related to virtually all other system assets. Stories represent discrete pieces of functionality that deliver business value. They can include:

  • Requirements for new functionality
  • Additions or changes to existing functionality
  • Details about activities the project team must perform to deliver the product
  • Non-functional requirements

Stories are managed in the backlog and belong to a project. They can be scheduled for work in a sprint or iteration.

Story Components​

All stories can be comprised of:

  • Acceptance Tests (or Tests): Define acceptance criteria for the functionality
  • Tasks: Define discrete work units for the team to complete to deliver the story

Story Relationships​

Stories have rich relationships within the Digital.ai Agility ecosystem:

  • Portfolio Items: Stories are often derived from larger-grained features called portfolio items, creating a hierarchy from strategic vision down to executable work
  • Backlog Groups: Stories can be grouped into flexible backlog groups, which can form a hierarchy above stories for organizational purposes
  • Backlog Goals or Objectives: Stories can be mapped to backlog goals or objectives using a many-to-many relationship, allowing a single story to contribute to multiple goals
  • Projects and Sprints: Each story belongs to a specific project and can be assigned to sprints for execution
  • Dependencies: Stories can have upstream and downstream dependencies with other stories or backlog items

Core Story Management Operations​

Digital.ai Agility provides comprehensive capabilities for managing the complete lifecycle of stories and backlog items.

Create, View, Edit, and Close​

The fundamental operations for working with backlog items cover the basic CRUD (Create, Read, Update, Delete) lifecycle:

  • Create: Add new backlog items inline in grids, through detail pages, via the sidebar, from spreadsheet imports, or from templates
  • View: Access comprehensive story details including all attributes, relationships, history, and visualizations
  • Edit: Update story information using inline grid editing, detail page editing, or field-specific pencil icon editing
  • Close: Mark stories as complete with the appropriate status, using either standard close or quick close operations

For detailed procedures, see Create, View, Edit, and Close Backlog Items.

Delete and Recover​

Deletion should be used sparingly and only when a story should never have existed:

  • Delete: Remove stories that were created in error, are duplicates, or are test data
  • Recover: Use Undo Delete to restore accidentally deleted stories, preserving all relationships, attachments, and child items

Best Practice: Close stories instead of deleting them to preserve historical reporting data for velocity and metrics.

For detailed procedures, see Delete and Recover Backlog Items.

Move Between Projects​

Transfer stories from one project to another when organizational needs change:

  • Move individual or multiple stories using grid actions, detail page edits, or bulk operations
  • Understand that moving stories between teams clears team-specific status values and rollup categories
  • Maintain story relationships and history during the move

For detailed procedures, see Move Backlog Items Between Projects.

Split Stories​

Splitting is used when a story is partially complete at the end of a sprint:

  • The completed work stays in the current sprint under the original story
  • The remaining work moves to the next sprint under a new story
  • Tasks and tests are allocated based on completion status
  • Splitting enables accurate accounting of work completed versus work remaining

Best Practice: Splitting should not be common practice. Size stories appropriately so individual estimates don't have large impacts on sprint velocity.

For detailed procedures, see Split Backlog Items.

Troubleshoot Access Issues​

Common issues and solutions for story access problems:

  • Cannot Edit: Check permissions, item status (closed), or sprint/project status
  • Cannot See: Verify Single Level Project View settings and project membership
  • Broken Images: Fix broken image resource links after server migrations

For detailed troubleshooting, see Troubleshoot Backlog Item Access.

Story Management Best Practices​

  1. Size Appropriately: Keep stories small enough to complete within a single sprint to minimize the need for splitting.
  2. Write Clear Acceptance Criteria: Use acceptance tests to define clear "done" criteria before work begins.
  3. Maintain Relationships: Link stories to portfolio items, dependencies, and goals to provide context and traceability.
  4. Use Templates: Create story templates for recurring types of work to ensure consistency and save time.
  5. Close Instead of Delete: Always close completed or abandoned stories to preserve historical reporting data.
  6. Track Dependencies: Identify and manage upstream and downstream dependencies to avoid blocking work.
  7. Leverage Backlog Groups: Organize related stories into backlog groups for easier navigation and planning.
  8. Map to Goals: Connect stories to backlog goals or objectives to ensure alignment with business outcomes.
  9. Breakdown with Tasks: Use tasks to decompose stories into manageable work units for team members.
  10. Monitor Story Age: Regularly review old stories in the backlog and either prioritize, close, or delete them to keep the backlog healthy.

Available Reports​

Digital.ai Agility provides extensive reporting capabilities for stories and backlog items:

Use Cases​

Backlog Refinement Session Using Inline Editing​

Scenario: Product owner conducts weekly backlog refinement with team, reviewing and updating 20+ stories in preparation for sprint planning.

Approach:

  1. Open Backlog page (Hamburger menu > Product > Backlog).
  2. Use inline grid editing to quickly update stories:
    • Click directly in Estimate field to add story points
    • Update Priority by clicking and selecting from dropdown
    • Edit Description inline for quick clarifications
    • Add or change Owner assignments
  3. Team discusses stories, product owner updates fields in real-time.
  4. Mark stories as "Ready" using Status field once acceptance criteria are clear.
  5. Drag and drop stories to reorder by priority.
  6. Session completes: 20 stories refined and ready for sprint planning.

Outcome: Efficient refinement session where team sees updates immediately, no need to open individual story details pages for minor updates.

Story Elaboration from Quick Creation to Full Detail​

Scenario: Team member creates story during brainstorming, then elaborates it with full details before sprint planning.

Approach:

  1. Quick creation (during brainstorming meeting):
    • Click + icon in header sidebar
    • Select "Story" from asset type
    • Enter Title: "Add password reset feature"
    • Select Project
    • Click Save
    • Story created in 30 seconds
  2. Later elaboration (before sprint planning):
    • Open story from Backlog grid
    • Navigate to Details page
    • Add comprehensive Description with user persona and scenario
    • Create 3 Acceptance Tests defining success criteria
    • Break down into 5 Tasks for team members
    • Add Estimate: 8 points after team discussion
    • Link to parent Portfolio Item (User Management Epic)
    • Add upstream dependency on "User Authentication API" story
    • Set Priority to High

Outcome: Story quickly captured when idea emerged, then fully elaborated with all context before team commits to work.

Template-Driven API Development​

Scenario: Team builds 15 REST API endpoints per sprint, needs consistent story structure for quality and estimation accuracy.

Approach:

  1. Create template (one-time setup):
    • Create story "API Endpoint Template"
    • Add standard Description template: 
      Endpoint: [METHOD] /api/v1/[resource]
      Purpose: [What it does]
      Request: [Body/params]
      Response: [Structure]
      Auth: [Requirements]
    • Add 5 standard Acceptance Tests:
      • Returns 200 for valid request
      • Returns 400 for invalid input
      • Returns 401 for unauthenticated request
      • Returns proper error messages
      • Response matches schema
    • Add 4 standard Tasks:
      • Implement endpoint logic
      • Write unit tests
      • Update API documentation
      • Test with Postman
    • Set default Estimate: 5 points
  2. Use template (every sprint):
    • Create new story from template
    • Customize Title and Description placeholders
    • Adjust Tasks if endpoint is simpler/more complex
    • Estimate adjusted from default 5 based on complexity
  3. Team creates 15 consistent API stories in 30 minutes instead of 2 hours.

Outcome: Standardized story structure ensures quality, reduces estimation variance, saves planning time.

Closing vs. Deleting: Managing Experimental Features​

Scenario: Team built experimental AI feature in previous quarter, stakeholders decided not to proceed with it.

Approach: Option A: Close stories (Recommended)

  1. Navigate to Backlog, filter by Epic "AI Recommendations".
  2. Select all 12 stories related to experimental feature.
  3. Bulk close stories with Status: "Closed".
  4. Add closing note: "Feature cancelled per stakeholder decision, code archived".
  5. Stories remain in system:
    • Historical velocity data preserved
    • Team completed 96 points of work (accurate velocity metric)
    • Burndown reports show correct completion trend
    • Future analysis can review what was learned

Option B: Delete stories (Not recommended)

  1. Would remove stories completely.
  2. Loses historical record of work completed.
  3. Velocity reporting becomes inaccurate (missing 96 points).
  4. No record of lessons learned.

Decision: Close stories, preserve history for accurate velocity and learning.

Outcome: Team maintains accurate velocity metrics, future planning uses correct historical data, organization retains knowledge of experiment.

Cross-Project Story Move During Team Reorganization​

Scenario: Company reorganizes teams, "Mobile App" project splits into "iOS" and "Android" projects. Need to move 30 stories to new projects.

Approach:

  1. Navigate to Mobile App project backlog.
  2. Filter stories by custom field "Platform" = "Android".
  3. Select all 30 Android stories using checkbox.
  4. Click Actions > Move to Different Project.
  5. Select target project: "Android".
  6. System warning: "Moving stories between teams clears team-specific status values".
  7. Acknowledge warning, confirm move.
  8. Result:
    • 30 stories now in Android project
    • Story numbers preserved (maintain traceability)
    • Sprint assignments cleared (Android team will reschedule)
    • Portfolio Item relationships maintained
    • Tasks and Acceptance Tests moved with stories
    • Status reset to default for Android project's workflow
  9. Android team reviews moved stories in their backlog.
  10. Re-assign stories to appropriate sprints in Android team's schedule.

Outcome: Stories successfully migrated to new team structure, relationships preserved, team can continue work with proper project context.

Frequently Asked Questions​

When should I split a story vs. create a new story?​

Split a story when:

  • Story is partially complete at end of sprint
  • Some tasks/tests are done, others remain
  • Want to give team credit for completed work
  • Need to accurately reflect velocity (completed portion stays in closed sprint)

Create a new story when:

  • Discovering additional scope that's separate from original story
  • Requirements changed significantly during sprint
  • Work is related but functionally independent

What's the difference between closing and deleting a story?​

Closing a Story (Recommended):

  • Marks work as complete while preserving all history
  • Closed stories count toward team velocity
  • Appear in historical reports and burndowns
  • Can be reopened by changing status

Deleting a Story:

  • Permanently removes story from system
  • All data lost (estimate, tasks, attachments, history)
  • Deleted stories excluded from velocity calculations
  • Only recoverable through admin restore from backup
  • Use only for duplicates, test data, or errors

Recommendation: Default to closing stories. Only delete obvious errors to preserve historical reporting data.

Can I move stories between projects without losing history?​

Yes, most data is preserved when moving stories:

What's preserved:

  • Story number, title, and description
  • Portfolio item relationships and dependencies
  • Tasks, acceptance tests, and attachments
  • Historical comments and change history

What changes:

  • Sprint assignment cleared
  • Team-specific status values reset to target project's default
  • Team assignment cleared

Best practices:

  • Document why stories are moving (add comment before move)
  • Notify affected teams before moving their work
  • Have target team re-assign stories to appropriate sprints
  • Test with 1-2 stories before bulk moving

Why can't I edit or create a story?​

Common reasons:

Closed story or sprint: Closed stories are read-only by default. Change status from "Closed" to "In Progress" to make editable, or move story to active sprint.

Insufficient permissions: Verify you have Team Member or higher role permissions. Owner alone doesn't guarantee edit rights. Check your role assignment (hamburger menu > My Profile).

Project is closed/archived: Closed projects lock all contained stories. Reopen project or move story to active project.

Field-level security: Specific fields may be restricted by role. Contact administrator to adjust field-level security rules.

How do I recover a deleted story?​

Immediate recovery (recommended):

  1. After deleting story, click "Undo" notification if displayed.
  2. Story restored with all relationships, attachments, and child items intact.

Recovery from audit trail:

  1. Click hamburger menu > Admin > Configuration > Audit.
  2. Search for deleted story by number or title.
  3. Contact system administrator to restore from backup.

Prevention: Always close stories instead of deleting to preserve history. Use bulk operations carefully and restrict delete permissions.

Last updated on