Handling partially completed requirements when moving stories to next sprint

ALM Atlassian Jira Software
, , , , , , ,
1

When we move stories that represent requirements from one sprint to the next in Jira 8, we’re losing visibility into what was actually completed versus what’s still pending. Each requirement story has multiple acceptance criteria modeled as subtasks, but when the story moves to the next sprint, all subtasks move with it, making it unclear which criteria were met in the previous sprint.

Here’s what’s happening:


Requirement Story: "User can reset password"
  ├─ Subtask: Email validation [Done]
  ├─ Subtask: Token generation [Done]
  └─ Subtask: Password strength check [To Do]

When we move this story to Sprint 2, all three subtasks move together, and our sprint review reports show zero completed work for this requirement in Sprint 1, even though two acceptance criteria were actually met.

This is causing poor visibility into partial progress and confusing sprint reviews with stakeholders. How should we model acceptance criteria and track requirement completion across sprint boundaries?

2

For sprint reviews, you might want to look at velocity tracking based on story points rather than issue count. If you assign story points to each subtask (representing each acceptance criterion), then even if the parent moves, the velocity report will show the points completed in Sprint 1 from the finished subtasks. This gives you visibility into partial progress without changing your issue structure.

3

Let me provide a comprehensive solution that addresses all three focus areas: modeling acceptance criteria as subtasks, using custom fields for requirement completion, and understanding sprint carry-over behavior.

Problem Analysis:

The core issue is that Jira treats subtasks as tightly coupled to their parent story. When you move a story between sprints, Jira’s default behavior is to move all subtasks with it, which breaks your ability to track partial completion in sprint reviews.

Solution 1: Modeling Acceptance Criteria as Subtasks (Current Approach, Optimized)

If you want to keep using subtasks for acceptance criteria, you need to handle sprint carry-over manually:

Step 1: Configure Sprint Carry-Over Behavior

Jira 8 has a setting that controls whether subtasks move with parents. Go to:

Board Settings → General → “Allow subtasks to be in a different sprint than their parent”

Enable this setting. This allows subtasks to remain in their original sprint even when the parent moves.

Step 2: Manual Sprint Assignment for Completed Subtasks

When moving a partially completed requirement story to the next sprint:

  1. Move the parent story to Sprint 2 (this will initially move all subtasks)
  2. For each completed subtask, manually edit and change sprint back to Sprint 1
  3. Incomplete subtasks remain in Sprint 2 with the parent

This preserves sprint history but is tedious. To automate:

Step 3: Automation Rule to Preserve Completed Subtask Sprints

Create a Jira automation rule:

  • Trigger: Issue moved to a different sprint
  • Condition: Issue type = Story AND has subtasks
  • Action: Branch on subtasks where status category = Done
  • Sub-action: Set sprint field to {{parent.originalSprint}}

This automatically keeps completed subtasks in their original sprint when the parent moves.

Solution 2: Using Custom Fields for Requirement Completion

A more robust approach is to track completion percentage on the parent story using a custom field:

Step 1: Create Custom Fields

Create two custom fields on Story issue type:

  • “Acceptance Criteria Completed” (Number field)
  • “Acceptance Criteria Total” (Number field)
  • “Completion Percentage” (Calculated field or automation-updated Number field)

Step 2: Automation Rule to Calculate Completion

Create an automation rule that triggers when any subtask changes status:


// Pseudocode - Key implementation steps:
1. Trigger: Issue transitioned (subtask)
2. Action: Get parent issue
3. Action: Lookup issues - all subtasks of parent
4. Action: Count subtasks where status category = Done
5. Action: Update parent field "Acceptance Criteria Completed" with count
6. Action: Update parent field "Acceptance Criteria Total" with total count
7. Action: Calculate percentage: (completed / total) × 100
8. Action: Update parent field "Completion Percentage" with result

This gives you a real-time completion percentage on each requirement story that persists across sprint moves.

Step 3: Sprint Review Reporting

Create a custom JQL filter for sprint reviews:


sprint = "Sprint 1"
AND "Completion Percentage" > 0
AND status != Done
ORDER BY "Completion Percentage" DESC

This shows all partially completed requirements from Sprint 1, even if they’ve moved to Sprint 2.

Solution 3: Sprint Carry-Over Behavior for Subtasks vs. Parents

Understanding Jira’s sprint mechanics is crucial:

How Jira Handles Sprint Assignment:

  1. Parent Story: Sprint field is a single value. When you move a story from Sprint 1 to Sprint 2, the sprint field changes from “Sprint 1” to “Sprint 2”. The story no longer appears in Sprint 1 reports.

  2. Subtasks: Subtasks have their own sprint field (if enabled in board settings). By default, subtasks inherit the parent’s sprint, but can be assigned independently.

  3. Velocity Calculation: Jira’s velocity report aggregates story points based on the sprint field value. If a subtask is in Sprint 1 and has 3 points, those 3 points count toward Sprint 1 velocity, regardless of where the parent is.

Key Insight: Story Points Assignment Strategy

To track partial completion correctly, you must assign story points at the subtask level, not the parent level:

Before (Parent-Level Points):


Requirement Story: "User can reset password" [8 points]
  ├─ Subtask: Email validation [0 points]
  ├─ Subtask: Token generation [0 points]
  └─ Subtask: Password strength check [0 points]

Problem: When story moves to Sprint 2, all 8 points move with it, even if 2 subtasks are done.

After (Subtask-Level Points):


Requirement Story: "User can reset password" [0 points]
  ├─ Subtask: Email validation [3 points] - Sprint 1, Done
  ├─ Subtask: Token generation [3 points] - Sprint 1, Done
  └─ Subtask: Password strength check [2 points] - Sprint 2, To Do

Benefit: When story moves to Sprint 2, 6 points remain credited to Sprint 1 (from completed subtasks), and only 2 points move to Sprint 2.

Implementation Steps:

  1. Migrate existing stories: For each requirement story with parent-level points:

    • Divide parent points among subtasks based on relative effort
    • Set parent points to 0
    • Assign points to each subtask

  2. Update team practices: Train team to estimate at subtask level during sprint planning

  3. Adjust velocity tracking: Jira will now aggregate subtask points for velocity reports automatically

Solution 4: Alternative Modeling - Acceptance Criteria as Linked Stories

If subtask management becomes too cumbersome, consider modeling acceptance criteria as separate story issues:

Structure:


Requirement Epic: "Password Reset Feature"
  ├─ Story: Email validation [Sprint 1, Done]
  ├─ Story: Token generation [Sprint 1, Done]
  └─ Story: Password strength check [Sprint 2, To Do]

Link these stories to the Epic using “implements” or “satisfies” link type.

Benefits:

  • Each acceptance criterion is an independent story with its own sprint assignment
  • No carry-over complexity-done stories stay in their sprint naturally
  • Better visibility in sprint reports (each story shows up individually)
  • Team can work on acceptance criteria in parallel across multiple sprints

Drawbacks:

  • More issues to manage (3 stories instead of 1 story + 3 subtasks)
  • Requires discipline to keep stories linked to parent Epic
  • Epic-level reporting needed to see overall requirement status

Recommended Approach (Best Practice):

Combine Solution 1 (subtasks with proper sprint handling) and Solution 2 (custom completion fields):

  1. Model acceptance criteria as subtasks (keeps them visually grouped under requirement)
  2. Assign story points at subtask level (enables accurate velocity tracking)
  3. Enable subtask sprint independence (allows completed subtasks to stay in original sprint)
  4. Add completion percentage custom field (provides at-a-glance progress visibility)
  5. Create automation rules to:
    • Calculate completion percentage when subtasks change status
    • Preserve completed subtask sprints when parent moves
    • Add comment to parent when moved with partial completion

Sprint Review Reporting Setup:

Create a custom dashboard for sprint reviews with these gadgets:

  1. Velocity Chart: Shows points completed per sprint (will correctly show partial completion from subtasks)
  2. Sprint Report: Filtered to show issues with completion percentage > 0 and < 100
  3. Custom Filter Results: JQL showing carried-over requirements:

project = REQ
AND sprint = "Sprint 2"
AND "Completion Percentage" > 0
AND "Completion Percentage" < 100

Stakeholder Communication:

During sprint reviews, present carried-over requirements with context:

  • “Requirement REQ-123 was 67% complete in Sprint 1 (2 of 3 acceptance criteria met)”
  • “The completed criteria (Email validation, Token generation) delivered 6 story points”
  • “The remaining criterion (Password strength check) carries 2 points into Sprint 2”

This gives stakeholders clear visibility into partial progress and avoids the perception that incomplete stories represent zero value.

Handling Edge Cases:

  1. Story moved multiple times: Completion percentage tracks cumulative progress across all sprints
  2. Subtasks added mid-sprint: Automation recalculates total and percentage automatically
  3. Subtasks reopened: Percentage decreases, reflecting actual state
  4. Parent story completed with incomplete subtasks: Add validation rule to prevent story completion until all subtasks are done

This comprehensive approach has worked well for teams managing complex requirements across multiple sprints. The key is decoupling subtask sprint assignment from parent sprint assignment and using story points at the subtask level to track partial completion accurately.

4

Marco, can you clarify the manual move option? If I move the parent story to Sprint 2, can I leave some subtasks in Sprint 1? I thought Jira automatically moves all subtasks with the parent. And for the custom field approach, how would I calculate the completion percentage-would that be manual or can it be automated?

5

You should assign points only to subtasks if you want sprint carry-over tracking to work correctly. Leave the parent story at 0 points. Jira’s velocity reports will aggregate subtask points up to the parent for reporting purposes, but the sprint assignment of each subtask determines which sprint gets credit for the work. This way, when you move the parent to Sprint 2, the completed subtasks stay attributed to Sprint 1 in velocity calculations.

6

This is a common issue with using subtasks for acceptance criteria. Subtasks are tightly coupled to their parent-when the parent moves, all subtasks move. You have a few options: either keep completed subtasks in the original sprint (requires manually moving the parent without children), use a custom field to track completion percentage on the parent story, or model acceptance criteria as separate story issues linked to the requirement rather than as subtasks.

7

Dan, we already use story points, but they’re assigned at the parent story level, not the subtask level. If I start assigning points to subtasks, won’t that double-count the effort? Or should I remove points from the parent and only assign them to subtasks? That seems like it would break our velocity tracking at the story level.