Manage Unfinished Work
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
Watch the video below to see an overview of the story splitting process:
From the detail page of the story you want to split:
If a field is hidden for the project, it will not display on the story splitting screen.
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 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:
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.