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 features and 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 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
Based on how your team and organizations use CA Agile Central, you will need to choose one of two options for handling the unfinished work. Each option has different impacts on reporting and charts:
- Move the story out of the recently completed iteration, preferably into the next iteration. This method makes management of the unfinished story easy, but may negatively affect historical iteration charts.
- Split the story in two, leaving a history of unfinished work in the recently completed iteration. This method preserves the fact that the total work planned in the iteration was not completed, but charts that track
, parent portfolio items, and time in process may never show 100% completion.
Review both the move and split options with your teams and organization, and decide on a standard way to handle this scenario. Consistency is important to retain historical records.
Move an Unfinished Story
When you move a user story, you simply edit the work item and change its Iteration value to reflect
in a new iteration. Unfinished work in a past iteration should be the top priority for the next iteration. Discuss this move in both your iteration retrospective and iteration planning meetings.
Follow these steps:
- Navigate to the detail page of the story you want to move.
- Change the Iteration
to the next upcoming iteration.
- Retain the same
- Edit the tasks under the story that were completed in the past iteration:
- Set the
and To-Do values to 0, to prevent completed task hours from affecting the next iteration's
- If your team is new and has temporarily activated the Actuals field, leave those values as-is.
- Add new tasks or update remaining task descriptions if necessary.
Impact of Moving an Unfinished User Story
Using this method can affect your statistics and charts in a few different ways.
The number of
in a moved story's Planned Estimate field will no longer be applied to the past iteration. This can impact the % done indicator on the Iteration Status page.
For example, a team plans 20 points worth of work into their iteration, but are unable to complete one of the 5 point stories in the plan. Prior to moving the incomplete story, the team's iteration correctly displayed that 15 points were accepted in the iteration, out of 20 planned. After moving the incomplete story into the next iteration, the team sees an incorrect chart value: 15 points were accepted, out of 15 total points planned. This can make it more difficult to locate historical failures or other events.
Other locations in CA Agile Central may show altered historical data:
- The Velocity chart will not display the fact that work was unaccepted or accepted late in the iteration.
- The Cumulative Flow chart will show a change in scope on the day the story is moved.
- The Iteration Scope Change report will show a story was removed from the plan, if the move is done on or before the last day of the
- If in-progress tasks are moved, "extra credit" can occur if the tasks have
values lower than the original Task Estimate. For example, if a moved story had 5 total task hours estimated, but only 3 hours remain, the next iteration's burndown will show 2 hours of work were completed on the first day. In reality, those hours were done during the past iteration, when the work was not completed.
Split an Unfinished Story
When you split a user story, the
is an unfinished story in the past iteration (as a historical placeholder) and a continuation of the story in the next iteration.
Tasks associated with the split story are parented to the stories under which they are listed. Tasks with a
of In-Progress and Defined display in the continued story. Completed tasks display in the unfinished story.
Tasks associated with the split story 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.
For the historical user story, we recommend that you:
- Leave all completed tasks and defects with the historical story.
- Remove the story from its parent.
- Leave the Plan Estimate unchanged so that you understand how many points you planned versus how many you actually accepted.
- Leave the
field unchanged so that you can easily see which user stories did not reach
during the iteration.
- Change the Release field to unscheduled. This action will retain the team's history in the iteration, but the overall release will correctly show that the planned work was eventually done. This assumes that the iteration the work was missed in and the iteration the work was completed in are both in the same release.
For the continued user story, we recommend that you:
- Retain the Plan Estimate value. You are not doubling-up! Teams get full velocity credit for their work in the iteration that the work is accepted.
- Assign 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.
When you split a user story, CA Agile Central will automatically:
- Select the option to create a parent user story to connect both stories. De-select this option, as it is not recommended for teams using portfolio hierarchies.
- 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.
Impact of Splitting a Story
Splitting the story can affect your charts and statistics in the following ways:
If you do not remove the historical story from the release as recommended, Release Scope and Release Burnup charts will never achieve 100% acceptance, due to the unfinished work in the
If you do not remove the historical story from the feature parent, that feature's scope will be artificially inflated. The feature's burnup will never achieve 100% acceptance due to the unfinished work in the list of child user stories.
Advanced Insights charts such as Time in Process will be negatively impacted, because a story will never be finished or accepted.
Splitting a story causes two entries on the Release Scope Change report. Scope is added due to the new story creation, and scope is removed when you unschedule the unfinished work from the release.
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. When possible, continue the story in the same 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.
||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 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 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.