Losing a user story, defect, test case, or other type of Rally work items can be frustrating. With the exception of a permanent deletion by another user, it is unlikely that the missing item is gone forever. Below is a list of the most common reasons why you may not be able to find an artifact, and what to do to check or resolve each.
- Search first
- Work item deleted
- Revision histories
- Permissions changed
- Parent story deleted
- Parent story is not on the backlog
- Restore parent associations
If possible, it's best to search for the full Formatted ID of the missing artifact, such as US1103.
Work item deleted
A common cause for missing items is another member of your team deleted the artifact. If you cannot find your item through search, check the Recycle Bin next. The link for the Recycle Bin is at the bottom-right corner of any Rally page.
Default sorting will show the most recently deleted items at the top of the page. You can select the columns at the top to sort by other criteria, such as Name, Type, and Deleted By. Select the gear icon to the left of a work item to restore it.
For an iteration or release, a work item will be removed from these timeboxes if you delete the item or move it to another project. When deleting, the revision history will look like this:
When a work item is moved to another project, the revision will read the same, but will not include the Moved to Recycle Bin text.
If the missing item was attached to another artifact, you may see a revision like this:
If you have permission to a project that contains your stories, and an administrator then removes your permissions, you will no longer be able to see those work items.
The easiest way to check for a permission change is to go to the Setup → Profile page. Select the Revisions link. A revision looks like this:
You may also check with your subscription administrator to see if your access rights have been removed or modified.
Parent story deleted
A user story can be deleted inadvertently if it has a parent. When you delete a parent story, all child stories within are also deleted. When you attempt to delete a parent story, a pop-up displays asking you to verify you want to delete the parent story and all associated children.
When a group of parent and child stories is deleted, only the top-most story will display in the Recycle Bin page. To restore any children inside:
- Restore the parent user story from the Recycle Bin.
- Navigate back to the story in its original project.
- Edit the child user story that was missing.
- Click the red X icon that appears next to the Parent field.
- Save the changes. The child story is now independent.
- Delete the parent story once more, if necessary.
Parent story is not on the backlog
Consider the following about parent-child relationships:
- If you add a child user story to an existing user story (now a parent story), the parent story won't display on the Plan → Backlog page or the backlog view on the Plan → Plan page.
- When editing a parent user story, the Iteration and Release fields are disabled.
- If a user story is already assigned to an iteration or release, those fields are cleared out if the story is made a parent.
- If a user story has tasks assigned to it, those tasks are automatically moved to the new child story.
This behavior is in accordance with Agile methodology. When you create child stories underneath an existing story, the scope of work is too large to fit into a single iteration. Multiple child stories are completed during several iterations instead, and when all of the work in the children is complete, the status will roll-up to the parent story.
Since the backlog is a collection of work that is ready to be scheduled, and parents are too large to schedule, parents do not display in these locations.
If you are trying to denote a theme of work and do not want to use parent stories, consider these options:
- Use naming conventions in user stories to link them to a common theme.
- Example: US123 - [Website Redesign] - Improve functionality in Firefox.
- Use tags to track themes of work across user stories.
- Use the Tagged Story Burndown report for a graphical view of progress on all tagged stories.
Restore parent associations
When you delete a user story that has a parent, the association to the parent is automatically severed when the story is moved to the Recycle Bin. If the story is later restored, it will not be re-associated to the parent automatically.
Rally's database rules require this behavior, to prevent work items from being restored with an association to a work item that does not exist. For example, Story A is the parent of Story B. Story B is deleted, and a few days later, Story A is also deleted. If Story B is restored without these rules, it would show Story A as the parent, which is a null object. This could cause broken links and problems with various apps and pages.
However, because the association is removed immediately prior to a deletion, the ID and name of the former parent are preserved in the revision history. You may restore parent associations with the following method:
- Restore the child user story from the Recycle Bin.
- Navigate to the detail page of the story, then click the Revisions link on the sidebar.
- Find an entry prior to the delete that states PARENT removed [US123: Story One]. The Formatted ID and name of the former parent are in brackets.
- Ensure the former parent story is still available in your project.
- Edit the child user story, then click the search icon next to the Parent field.
- In the chooser that displays, enter the name or FormattedID of the former parent.
- Select the parent and save. The stories are now associated.
If you need to parent several restored user stories, consider using the Story Hierarchy app to do this efficiently.
Encourage your team members and co-workers to add their comments and votes to this topic in Rally Ideas to give us a better indication of the number of users interested in such functionality: Idea D2372: Restore parent relationships from items in the Recycle Bin.