There are several ways you can manage unfinished work:
As you finish your
, you may find that you did not complete all of the work that your team committed to finish. This can happen for a variety of reasons:
You Overestimated What You Could Complete in the Iteration
New teams that are still understanding their
may struggle with incomplete work for a few iterations. This is normal. Teams should continuously adjust their
for new iterations until unfinished work becomes the exception rather than the rule.
One of Your Work Items Ended Up Much Larger Than You Anticipated
At some point, all teams will encounter a work item that greatly surpasses its initial estimation, pushing out other work. If this becomes a common occurrence, the team should consider two preventive measures:
- Spend more time discussing, estimating, and tasking out user stories during iteration planning, or
- Rigorously break down larger user stories into smaller, value-add stories
A Work Item Became Blocked
Sometimes blockages can be avoided and other times they cannot. Always include blocked items as part of your iteration retrospective so that you have an opportunity to improve your process and communication for the next iteration.
Manage Unfinished User Stories
For each incomplete
, you'll want to work with your team to:
- Understand the root cause and how to avoid it next time.
- Discuss the future of the user story:
- Is it still a priority to work on this user story?
- Do we want to take a different approach this time?
- What work is remaining?
- Can we break this story down any further to reduce
- Use the Split option to disperse the remaining work into the next iteration (or
When you split a user story, the
is an unfinished user story in the past iteration (as an historical placeholder) and a continuation of the user story in the next iteration.
For the historical user story, we recommend that you:
- Leave behind all the completed tasks and defects.
- Leave the
unchanged so that you understand how many
you planned versus how many you actually accepted.
- Exception: If you are using a user story hierarchy or charts such as Story Burnup and Release Burnup, you may have a situation where the plan estimate roll-ups become artificially inflated due to unfinished work. To avoid this, you can either zero out the plan estimate on the unfinished user story or disconnect it from its parent user story or
- Leave the Schedule
unchanged so that you can easily see which user stories did not reach
during the iteration.
- Exception: If you are using a user story
and you want a parent user story to show 100% acceptance when it is truly finished, you may need to go back and accept all of the unfinished user stories. Do not include any part of the unfinished user story's plan estimate in your expected velocity when planning your next iteration. Taking partial credit, while appealing, can lead to overcommitment in future iterations.
For the continued user story, we recommend that you:
- Bring forward all the incomplete tasks, open defects, and test cases
- Re-evaluate the priority of the continued user story
- Discuss different approaches
- Break the story down to reduce risk, if possible
- Re-estimate the tasks based on the work remaining
These steps will reduce the risk of not finishing the user story a second time.
Split a User Story
When you split a user story, you can move tasks, defects, and test cases as well as edit the user story name,
, and estimate.
Tasks are parented to the stories under which they are listed. Tasks with a state of In-Progress and Defined display in the continued story. Completed tasks display in the unfinished story.
Defects with a Closed state or Accepted schedule state display in the Tasks grid on the unfinished story by default. Defects of all other states display on the continued story.
When you split a user story, CA Agile Central will automatically:
- Select the option to create a parent to connect both stories. If you do not want to connect the stories through a parent, de-select the checkbox option.
- Copy discussions and attachments forward with the continued user story.
Follow these steps:
- Navigate to the detail page of the story you want to split.
- From the ⋮ (Actions) menu, select Split.
The original story displays on the right with the Name field prepended with [Continued]. The new story displays on the left with the Name field prepended with [Unfinished]. The continued story is considered the split, or ongoing, story.
- Select a value for these fields:
Note: You cannot change the iteration of a
- Schedule State
- Plan Estimate
- To move tasks, defects, or test cases between the new and original stories, select the gear icon next to the work item you want to move, then select Move to other side.
- Ensure that you want to Create a parent to connect both stories. This option is selected by default.
- Select Split.
You are redirected to the detail page of the continued story.
Split Story Fields
You can set these field values when splitting a user story. If a field is hidden for the
, it will not display on the story splitting screen.
||You may change the names of the continued and unfinished stories. Be sure to use a name that is meaningful and contextual.
The current release is selected by default for the unfinished story. The next release is selected for the continued story by default. If a future release does not exist, it stays in the current release.
The current iteration is selected by default for the unfinished story. The next iteration is selected for the continued story by default. If a future iteration does not exist, it stays in the current iteration.
The default schedule state for the continued story is derived from the schedule states of the tasks on the story.
The default schedule state for the unfinished story remains in the same state before the split. The schedule state is rolled up from the tasks.
After splitting, the parent story reflects the rolled up state of the child stories.
||The original value defaults in the unfinished and completed stories.
Manage Unfinished Tests
Test cases may be present in an iteration through an attachment to a user story, defect, or
. Results for test cases are recorded in CA Agile Central as separate
, so you are not required to make a new copy of a test case for each iteration.
If you are unable to complete a defect that has an associated test case, edit the defect to move it into the next iteration.
If you are unable to complete a user story with an associate test case, follow the instructions to split a story. You will be able to move the test case between the old and continued copies of a user story as you may with tasks and defects.
If you are unable to complete a test set in an iteration, you may copy or move the test set. We recommend using the copy function to create a separate test set for the next iteration. The copy will include references to the same test cases assigned to the previous test set. This method allows you to keep any test case results that were run in the previous iteration separate from results in future iterations, and prevents naming confusion.