Manage Unfinished Work

Note: This page describes methods best suited for teams and organizations using portfolio hierarchies, with user stories directly associated to features. If your team does not use portfolio items, please see Manage Unfinished Work for Story Hierarchy Teams.

There are several ways you can manage unfinished work:

As you finish your iteration, 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 velocity may struggle with incomplete work for a few iterations. This is normal. Teams should continuously adjust their planned velocity 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 user story, 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 risk

Based on how your team and organizations use Rally, 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 release scope, 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 unfinished stories

When you move a user story, you simply edit the work item and change its Iteration value to reflect scheduling 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.

To move make the following changes to the story from its editable detail page:

  1. Change the Iteration field to the next upcoming iteration.
  2. Retain the same Plan Estimate value.
  3. Edit the tasks under the story that were completed in the past iteration:
    • Set the task Estimate and To-Do values to 0, to prevent completed task hours from affecting the next iteration's burndown chart.
    • 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

Using this method can affect your statistics and charts in a few different ways.

The number of points 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 Rally may show altered historical data:

  • The Enhanced Velocity and Velocity charts 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 current iteration.
  • If in-progress tasks are moved, "extra credit" can occur if the tasks have To Do 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 unfinished stories

When you split a user story, the result is an unfinished story in the past iteration (as a historical placeholder) and a continuation of the story in the next iteration.

For the historical user story, we recommend that you:

  • Leave all completed tasks and defects with the historical story.
  • Leave the Plan Estimate unchanged so that you understand how many points you planned versus how many you actually accepted.
  • Leave the Schedule State field unchanged so that you can easily see which user stories did not reach acceptance 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're 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 story and 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, Rally 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.

From the detail page of the story you want to split:

  1. From Actions, 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.

  2. Split Stories
  3. From the Iteration drop-down menu, select an iteration for the continued and unfinished stories.
  4. Select a value for these fields:
    • Release
    • Schedule State
    • Plan Estimate
  5. To move tasks, defects, or test cases between the new and original stories, click the gear icon next to the work item you want to move, then select Move to other side.
  6. Important! Ensure that the Create a parent to connect both stories option is de-selected. The option is selected by default.
  7. Click Split.

    You are redirected to the detail page of the continued story.

If a field is hidden for the project, it will not display on the story splitting screen. When you split a user story, the result is an unfinished user story in the past iteration (as an historical placeholder) and a continuation of the user story in the next iteration.

Tasks

After a split, 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

Defects with a Closed state or Accepted schedule state display in the Tasks grid in the unfinished story by default. Defects of all other states display in the continued story.

Impact

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 timebox.

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:

Field Description
Name You may change the names of the continued and unfinished stories. Be sure to use a name that is meaningful and contextual.
Release

The current release is selected by default for the unfinished story. The next release is selected for the continued story by default. When possible, continue the story in the same release.

Iteration

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.

Schedule State

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.

Plan Estimate 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 test set. Results for test cases are recorded in Rally as separate work items, 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.

Feedback

Need more help? The CA Agile Central Community is your one-stop shop for self-service and support. To submit feedback or cases to CA Agile Central Support, find answers, and collaborate with others, please join us at rallycommunity.rallydev.com.