Manage Unfinished Work

Print this topicEmail this topic

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 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 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 risk?
  • Use the Split option to disperse the remaining work into the next iteration (or backlog).

When you split a user story, the result is an unfinished user story in the past iteration (as a 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 plan estimate unchanged so that you understand how many points 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 release.
  • Leave the Schedule State field unchanged so that you can easily see which user stories did not reach acceptance during the iteration.
    • Exception: If you are using a user story hierarchy and you want a parent user story to show 100% acceptance when it's 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 story and tasks based on the work remaining

These steps will reduce the risk of not finishing the user story a second time.

Split user stories

When you split a user story, you can:

  • Move tasks, defects, and test cases
  • Edit the user story name, schedule state, and estimate

When you split a user story, Rally 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, simply de-select the checkbox option.
  • Copy discussions and attachments forward with the continued user story

Video

Watch the video below to see an overview of the story splitting process:

Split Unfinished User Stories
3 min

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.

    Note: You cannot change the iteration of a parent story.

  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. Ensure that you want to Create a parent to connect both stories. This 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.

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 on the unfinished story by default. Defects of all other states display on the continued story.

Split story fields

These field values can be set 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. If a future release does not exist, it stays in the current 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.

After splitting, the parent story reflects the rolled up state of the child stories.

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

Feedback

Please send us your feedback regarding our help site. For feedback regarding the Rally product, click here to open a support case or click here to submit a new feature request
English
By submitting this form, you accept the Mollom privacy policy.
© 2014 Rally Software Development Corp | Legal