CAPM Practice: Determine how to plan project iterations

Incomplete sprint backlog items are returned to the product backlog (not automatically accepted or deleted). The product owner then re-prioritizes them — they may go back to the top of the backlog if still high priority, or slip in priority if other items have become more important. They are available for future sprint planning based on their updated priority.

**Why not A:** Removing incomplete stories from the backlog entirely would waste the analysis, estimation, and refinement effort already invested. Incomplete stories are not failed stories — they simply did not fit within the sprint's capacity. Discarding them ignores potentially high-value work that the product owner may still prioritize.

**Why not B:** Automatically marking incomplete stories as completed would violate the Definition of Done and compromise product quality. Only work that meets all completion criteria should be accepted. Marking unfinished work as done creates a false sense of progress and hides technical debt.

**Why not D:** Assigning individual developers to work outside the sprint structure undermines the self-organizing, team-based nature of Scrum. Work should be planned within sprints through the product owner's prioritization, not assigned as off-cycle individual tasks that bypass the team's collaborative planning process.