Skip to main content

Split Backlog Items

Split partially completed backlog items across sprints to accurately account for completed and remaining work when stories cannot be finished in a single iteration.

Who splits backlog items: Scrum masters split stories during sprint close when work remains incomplete, ensuring accurate velocity tracking. Product owners coordinate splits to give credit for completed work while moving remaining effort to future sprints. Team members provide estimates for the split portions based on work completed versus remaining.

Permission requirement: Splitting backlog items requires edit permissions on the item (typically Team Member role or higher). You must also have edit permissions in both the current sprint (where the original item stays) and the destination sprint (where the new item goes). Splitting items in closed sprints requires reopening the sprint first. Specific permissions depend on your organization's role configuration.

note

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

When to Split Backlog Items​

Splitting a backlog item is typically done at the end of a sprint or iteration when a story is partially complete. The split operation:

  • Keeps the completed portion of work in the current sprint under the original backlog item
  • Moves the remaining work to the next sprint under a new backlog item
  • Allows you to give credit for completed work
  • Enables accurate accounting of velocity and sprint metrics

Important: Splitting is not the same as copying. You cannot split the same backlog item multiple times.

Before You Split​

Best Practice: Splitting should not become common practice. Backlog items should be sized appropriately so that the estimate from any one backlog item does not have a large impact on the velocity of a sprint or iteration.

If you end a sprint with multiple backlog items that need to be split, it's often a sign that your team has too much work-in-progress. It's much better to finish one backlog item than to end up with two that are half-done.

How Splitting Affects Tasks, Tests, and Attachments​

Understanding how child items are handled during a split helps you prepare and adjust after the operation.

If the backlog item has...Then...
Tasks or TestsTasks and tests are handled based on completion status:

Completed (To Do = 0): Completed tasks or tests stay with the original backlog item in the existing sprint.

Not Started (Done = 0): Not started tasks or tests are moved to the new backlog item in the next sprint.

Partially Completed (some Done and some To Do): Partially completed tasks or tests are copied to the new backlog item in the next sprint and remain with the original backlog item in the existing sprint. The To Do on the tasks or tests in the existing sprint is set to 0. All Done stays with the tasks or tests in the existing sprint. The To Do amount at the time of the split is assigned to the tasks or tests in the next sprint.
AttachmentsAttachments are not carried forward during the split process. As a workaround, you can copy the item instead of splitting it. Copies retain all relationships of the original, including links and attachments. The trade-off is that you would need to manually adjust your estimates on the two items.

Split Backlog Items​

Choose the method that works best for your workflow.

Option 1: In Any Grid​

Use this option to split a backlog item from any grid view.

  1. Click the hamburger icon Hamburger icon > Product > Backlog.
  2. Locate the backlog item you want to split.
  3. Click the drop-down arrow next to the backlog item and select Split.
  4. On the Split page, review the details and modify as necessary.
  5. Click the Split button.
  6. Make any additional changes to the fields (note that fields highlighted in yellow are pending).
  7. Click Save.

Fields you can edit during split:

  • Title: Change the title of the new backlog item to make it unique (e.g., "User Login Part 1" and "User Login Part 2")
  • Estimate: Allocate the estimate appropriately across the two backlog items based on actual value delivered
  • Detail Estimate and To Do: Verify the Detail Estimate and To Do amounts for the remaining workload are appropriate

Option 2: On the Team Scheduling Page​

Use this option to split a backlog item while viewing the team's sprint schedule.

  1. Click the hamburger icon Hamburger icon > Release > Team Scheduling.
  2. Click on a backlog item (either from the Team to which it is assigned or from the Backlog grid) to open the backlog item details page.
  3. Open the Edit drop-down menu and select the Split option.
  4. The Split Backlog Item window opens, showing details of the backlog item with remaining work estimate.
  5. Click the Split button. The system generates a new backlog item with the same name as the original. The remaining work estimate is transferred to the new backlog item. Completed estimates remain with the original backlog item.
  6. In the New Item section, select a sprint from the Sprint drop-down list.
  7. Click Save next to the new item to save the new backlog item details.
  8. Click Save at the top of the window. The new backlog item is assigned to the team who worked the original backlog item, and the item shows in the Team box with the inherited work estimate.

After Splitting​

Once you've split a backlog item, consider these follow-up actions:

  • Update Titles: Ensure both the original and new backlog items have clear, distinct titles
  • Verify Estimates: Confirm that the estimate allocation accurately reflects the work completed versus remaining
  • Check Sprint Assignment: Verify the new backlog item is assigned to the appropriate future sprint
  • Review Tasks: Check that tasks are correctly distributed between the original and new backlog items
  • Communicate: Notify the team about the split so they understand which work is complete and which continues

Best Practices​

  1. Size Stories Appropriately: Write stories small enough to complete within a sprint to minimize the need for splitting.
  2. Split Only When Necessary: Use splitting as an exception, not a regular practice. Frequent splitting indicates stories are too large.
  3. Split at Sprint End: Perform splits at the end of a sprint during sprint retrospective or planning to maintain clean sprint boundaries.
  4. Allocate Estimates Accurately: Be honest about the value delivered. If little progress was made, allocate most of the estimate to the new item.
  5. Update Titles Immediately: Change titles during the split operation to avoid confusion between the original and new items.
  6. Verify Task Distribution: After splitting, review tasks to ensure they're assigned to the correct backlog item based on completion status.
  7. Handle Attachments Manually: If attachments are critical for the remaining work, consider copying the item instead of splitting, or re-attach documents to the new item.
  8. Assign to Next Sprint: Immediately assign the new backlog item to a future sprint to ensure it doesn't get lost in the backlog.
  9. Learn from Splits: Use split occurrences as a retrospective topic to improve story sizing and decomposition practices.
  10. Consider Copying Instead: If you need to preserve attachments and all relationships, use Copy instead of Split and manually adjust estimates.

Use Cases​

End-of-Sprint Triage with Multiple Partial Stories​

Scenario: Sprint review reveals 3 stories partially complete, team needs to split them to accurately reflect completed work.

Approach:

  1. Story 1: "Payment Processing" (13 points, 60% complete)

    • Split from Backlog grid
    • Original story (Sprint 5, closed): 8 points completed
      • Tasks completed: "Integrate Stripe API", "Handle success responses"
      • Tests completed: "Test successful payment"
    • New story (Sprint 6, open): 5 points remaining
      • Tasks moved: "Handle payment failures", "Add retry logic"
      • Tests moved: "Test declined card", "Test network timeout"
    • Update titles: "Payment Processing - Success Flow" and "Payment Processing - Error Handling"

  2. Story 2: "User Dashboard" (8 points, 75% complete)

    • Split using Team Scheduling page
    • Original: 6 points completed (Sprint 5)
    • New: 2 points remaining (Sprint 6)
    • Most tasks completed, only "Polish UI animations" remains

  3. Story 3: "Search Functionality" (5 points, 40% complete)

    • Decision: Don't split, move entire story to Sprint 6
    • Reason: Only 2 points completed, splitting creates confusion
    • Team acknowledges overcommitment, will improve sizing

Outcome: Sprint 5 velocity accurately shows 14 points completed (8+6), Sprint 6 starts with 7 points of known work (5+2), team learns to size better.

Task Allocation Strategy During Split​

Scenario: Story "API Integration" has 6 tasks with mixed completion status, need to split carefully to maintain accurate task tracking.

Approach: Before split status:

  • Task 1: "Design API schema" - To Do: 0, Done: 4 (Completed)
  • Task 2: "Implement endpoints" - To Do: 2, Done: 6 (Partially complete)
  • Task 3: "Write unit tests" - To Do: 8, Done: 0 (Not started)
  • Task 4: "Integration testing" - To Do: 6, Done: 0 (Not started)
  • Task 5: "Update documentation" - To Do: 3, Done: 2 (Partially complete)
  • Task 6: "Code review" - To Do: 2, Done: 0 (Not started)

Split operation:

  1. Click Split from grid
  2. System automatically allocates:

Original story (Sprint 3, closed):

  • Task 1: Done: 4, To Do: 0 (stays, completed)
  • Task 2: Done: 6, To Do: 0 (stays with Done, To Do zeroed)
  • Task 5: Done: 2, To Do: 0 (stays with Done, To Do zeroed)
  • Estimate: 12 points completed

New story (Sprint 4, open):

  • Task 2: Done: 0, To Do: 2 (copied, gets remaining To Do)
  • Task 3: Done: 0, To Do: 8 (moved, not started)
  • Task 4: Done: 0, To Do: 6 (moved, not started)
  • Task 5: Done: 0, To Do: 3 (copied, gets remaining To Do)
  • Task 6: Done: 0, To Do: 2 (moved, not started)
  • Estimate: 21 points remaining
  1. Team reviews and adjusts:
    • Combines duplicate Task 2 and Task 5 entries in new story
    • Updates Task 2 name to "Complete endpoint implementation"
    • Updates Task 5 name to "Complete documentation"

Outcome: Clear separation of completed vs. remaining work, team knows exactly what's left, velocity tracking accurate.

Dependency Management During Story Split​

Scenario: Story "Frontend Dashboard" has downstream dependency from "Backend API" story, needs splitting due to partial completion.

Approach: Before split:

  • Story A: "Backend API" (Sprint 2, completed) → upstream
  • Story B: "Frontend Dashboard" (Sprint 3, partially complete) → downstream
  • Dependency status: Originally green (satisfied)

Split operation:

  1. Split "Frontend Dashboard" story
  2. Original: "Frontend Dashboard - Data Display" (Sprint 3, closed, 5 points)
  3. New: "Frontend Dashboard - Filters & Search" (Sprint 4, open, 3 points)

After split - Verify dependencies:

  1. Check original story dependencies: Still has upstream dependency on "Backend API" ✓
  2. Check new story dependencies: Also has upstream dependency on "Backend API" ✓
  3. Review dependency status:
    • Both stories depend on completed backend (Sprint 2)
    • Dependency status: Green for both (upstream completed before downstream)

Additional downstream dependency found:

  • Story C: "Mobile App Dashboard" (Sprint 4) depends on "Frontend Dashboard"
  • After split, need to clarify: Does Mobile App depend on original (now closed) or new (still open)?
  • Team decision: Update dependency to point to new story (filters needed for mobile)
  • Navigate to Story C details, update upstream dependency

Outcome: Dependencies correctly maintained after split, team avoids broken dependency chains, mobile team knows to wait for Sprint 4 completion.

Splitting vs. Copying Decision Matrix​

Scenario: Story "User Profile Page" partially complete with many attachments (mockups, design specs), team needs to decide split vs. copy approach.

Approach: Analyze story state:

  • Estimate: 13 points, 50% complete (6-7 points done)
  • Tasks: 8 tasks, 4 completed, 4 remaining
  • Attachments: 12 files (wireframes, design specs, API docs)
  • Links: 3 external documentation links
  • Comments: 15 comment threads with design decisions

Option A: Split (standard approach)

  • ✅ Accurate velocity tracking (completed work stays in closed sprint)
  • ✅ System handles task distribution automatically
  • ❌ Attachments don't copy to new story
  • ❌ Need to manually re-attach 12 files to new story
  • ❌ Comment threads split between two stories

Option B: Copy

  • ✅ All attachments, links, comments copied to new story
  • ✅ Design context preserved in new story
  • ❌ Must manually adjust estimates (original: 7 points, copy: 6 points)
  • ❌ Must manually mark completed tasks as done in original
  • ❌ Must manually delete completed tasks from copy
  • ❌ Velocity tracking less accurate (need discipline to update estimates)

Team decision: Use Split, then re-attach critical files

  1. Perform split operation
  2. Original story (Sprint 3, closed): 7 points
  3. New story (Sprint 4, open): 6 points
  4. Identify 3 critical attachments needed for remaining work:
    • Profile-fields-spec.pdf
    • Profile-API-integration.md
    • Updated-mockup-v3.png
  5. Download from original story, upload to new story (5 minutes)
  6. Add comment in new story referencing original story for full design history

Outcome: Accurate velocity with minimal manual work to preserve essential attachments.

Frequently Asked Questions​

How does splitting affect velocity calculations?​

Splitting correctly maintains velocity accuracy by separating completed work from remaining work:

Completed work (original story):

  • Estimate allocated to completed work counts toward sprint velocity
  • Example: 13-point story split into 8 points completed (original) and 5 points remaining (new)
  • Sprint velocity includes only the 8 completed points
  • Burndown chart shows accurate progress

Remaining work (new story):

  • Estimate for remaining work does NOT count toward closed sprint velocity
  • New story starts in future sprint backlog
  • Prevents "double-counting" the same work across sprints

Impact: Without splitting, moving entire story to next sprint shows 0 points completed (inaccurate). With splitting, sprint shows actual points completed (accurate reflection of work done).

What happens to attachments when I split a story?​

Attachments are NOT copied during split:

  • All attachments remain with the original story only
  • New split story starts with zero attachments
  • Workaround: Manually download attachments from original and upload to new story
  • Alternative: Use Copy instead of Split if attachments are critical (then manually adjust estimates)

What IS preserved:

  • Portfolio item relationships on both stories
  • Backlog group relationships
  • Goal/objective mappings
  • Dependencies (upstream and downstream) inherited by new story

Best practice: Review dependencies after split to ensure they're assigned correctly to the appropriate story.

Why would I split instead of just moving the entire story to the next sprint?​

Split when you need to give credit for partial work completed; move when little to no progress was made.

Use Split when:

  • Story is 40%+ complete (significant progress made)
  • Multiple tasks or tests completed
  • Team invested substantial effort (multiple days)
  • Want accurate velocity tracking

Move entire story when:

  • Story is less than 20% complete (minimal progress)
  • Only discovery or research done, no deliverable work
  • Splitting creates unnecessary administrative overhead

Rule of thumb: If team would feel cheated not getting credit for work done → Split. If team barely touched the story → Move.

Why can't I split a backlog item or why don't splits work as expected?​

Split option missing or disabled:

  • Verify you have edit permissions on the item (Team Member role or higher)
  • Item may already be closed (reopen it before splitting)
  • Item may have been previously split (items cannot be split multiple times)
  • Item may be in a closed sprint or project (reopen the container first)

Tasks and tests don't split correctly:

  • Task distribution follows completion status: fully complete tasks stay with original, not-started tasks move to new item, partially complete tasks are copied to both
  • Verify task completion values (Done/To Do) were accurate before splitting
  • Manually adjust task assignments after split if needed

Estimates don't match expectations:

  • Split operation uses snapshot values at time of split
  • If Detail Estimate wasn't updated during sprint, allocation may be inaccurate
  • Manually adjust estimates on both items after split if needed

Attachments missing:

  • Attachments intentionally don't transfer (known limitation)
  • Manually download from original and upload to new item
  • Or use Copy instead of Split if attachments are critical
Last updated on