Missing Work Items

Losing a user story, defect, test case, or other type of CA Agile Central 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 a work item, and what to do to check or resolve each.

Search First

When you can no longer find a work item, the first thing to do is search for it. The search field in the upper-right corner of any CA Agile Central page will scan the entire workspace for the work item.

If possible, it's best to search for the full Formatted ID of the missing work item, such as US1103.

When searching, it's best to be logged in as a workspace or subscription administrator. This ensures that if the work item was in a project your user no longer has access to, it will be included in search results. See the Permissions changed section below.

Work Item Deleted

A common cause for missing items is another member of your team deleted the work item. If you cannot find your item through standard search, select the Recycle tab on the search page to view matching items that have been deleted.

Select the gear icon to the left of a work item to restore it.

Note: Like any CA Agile Central page, search results are pinned to your project picker. Make sure you are looking at the proper workspace or project that the missing item was from, and that you have proper access permissions.

Release or Iteration Deleted

There is no recovery, undo, or revision histories for deleted releases and iterations. If you delete a release that iterations are scheduled in, they will all be updated to unscheduled. If you delete an iteration that stories and defects are scheduled in, they will all be updated to unscheduled.

Revision Histories

If the missing work item was associated to another item in CA Agile Central—a user story, defect, iteration, release—you can check the other item's revision history to find the missing work item.

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:

Revision history image

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 work item, you may see a revision like this:

Revision history example

Permissions Changed

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:

Revision history example

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. This applies to all work items that can be in a parent-child relationship, including user stories, defects, tasks, and portfolio items. 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:
  1. Restore the parent user story from the Recycle Bin.
  2. Navigate back to the story in its original project.
  3. Edit the child user story that was missing.
  4. Select the red X icon that appears next to the Parent field.
  5. Save the changes. The child story is now independent.
  6. Delete the parent story once more, if necessary.
If these suggestions do not help you with locating a missing work item, please Contact Support and we will be happy to continue investigation.

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

CA Agile Central'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:
  1. Restore the child user story from the Recycle Bin.
  2. Navigate to the detail page of the story, then click the Revisions link on the sidebar.
  3. 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.
  4. Ensure the former parent story is still available in your project.
  5. Edit the child user story, then click the search icon next to the Parent field.
  6. In the chooser that displays, enter the name or FormattedID of the former parent.
  7. 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 CA Agile Central Ideas to give us a better indication of the number of users interested in such functionality: Idea D4264: Restore parent relationships from items in the Recycle Bin.


Benötigen Sie weitere Informationen? Die CA Agile Central-Community ist Ihre zentrale Anlaufstelle für Self-Service und Support. Treten Sie der CA Agile Central-Community bei, um dem CA Agile Central-Support Feedback mitzuteilen oder Fälle zu melden, Antworten zu finden oder mit anderen Benutzern zusammenzuarbeiten.