Manage Unfinished Work
There are several ways you can manage unfinished work:
- Manage unfinished user stories
- Move unfinished stories
- Split unfinished stories
- Manage unfinished tests
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:
- Change the Iteration field to the next upcoming iteration.
- Retain the same Plan Estimate value.
- 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.
Using this method can affect your statistics and charts in a few different ways.
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:
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.
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 in the unfinished story by default. Defects of all other states display in the continued story.
Splitting the story can affect your charts and statistics in the following ways:
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:
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.