Problem: Entities in work hierarchy are orphaned and belong to different scopes of work | Targetprocess - Visual management software

Problem: Entities in work hierarchy are orphaned and belong to different scopes of work

Q: Why is it that when I move an epic into a different project, associated features, user stories, bugs and tasks don't move along with it? Is there a way to do this?

A: Indeed hierarchical links (such as Epic > Feature > User Story > Bug) in Targetprocess do not always limit assignment of all work items to the same Project / Release etc. The system allows these links and does not consider them as invalid ones.

We plan to make it possible to move a Feature with all its Stories across Projects quickly and easily. This action will be released soon.

For other use cases there we can recommend the following workarounds: filtered views, automatic custom rules and webhooks.

Filtered views

These views may be created and used by power users to detect orphaned entities and correct broken and missing dependencies manually.

Example of such view: Show Features that are parts of Epics from other Projects.

Cards: Features
Filter: ?Epic is not None and Project.Id != Epic.Project.Id

Custom Rules

Use automatic Custom Rules for the use cases that are supported by existing rules. Activate custom rules that fit your needs to prevent issues in future.

An active Custom Rule does not correct existing broken dependencies. They should be still fixed manually.

If you would like to activate one of the rules or check status of your existing rules, you're welcome to do the following. Being an Administrator, find them at Settings -> System Settngs -> Custom Rules -> Activate.

Most likely the ones below will be most helpful:

  • Assign team of a story to all its tasks and bugs
  • Assign team of a feature to all its stories and bugs
  • Assign a Project’s Team to a User Story
  • Assign a User Story’s Feature to a Bug

More rules are on the way. So far we postponed implementation of other missing rules. However we continure to gather the use cases on UserVoice.

Use cases

Project of Feature vs Project of its User Stories

Starting from v3.11.3 User stories will now follow their parent Feature.

Previously, if you moved a Feature to another Project, its User Stories did not follow the Feature to the new Project. This was fairly counter-intuitive. Starting with this release, if you move a Feature to a different Project, all of its User Stories will follow (as long as they were originally in the same Project as their parent Feature).

If you move a Feature to a Project with a different process, you will get a warning that this change might cause you to lose some custom fields.

Release of Feature vs Release of its User Stories

Incomplete User Stories inherit Release field from their parent Feature when they are assigned to the same Project.

The reason behind it is that obviously we do not want Release burndown chart to be corrupted by moving completed user stories out. And to avoid mess and lost work issues we do not recommend to create stories in projects that are different from the parent Feature.

Create new user story

Release field of a new user story is set from Release field of its parent Feature. For this purpose you should create new user story in the same project where the Feature is.

Assign user story to feature

Release field of a Feature is inherited by open user stories from the same project that are not assigned to any release yet.

Assign feature to a release

Release field of a Feature is inherited by open user stories from the same project with similar value set into their Release fields.

Let's consider data sample. User Story U1 is part of Feature F1. User Story U1 is in the same project where F1 is. User Story U1 is not closed. Here are supported actions:

Use CaseActionResult
Feature F1 is not assigned to any Release

User Story U1 is also not assigned to any Release

move Feature to some Release R1U1 is moved to R1 together with F1
Feature F1 is in Release R1

User Story U1 is also in Release R1

move Feature to other Release R2U1 is moved to R2 together with F1

Team Iteration of User Story vs Team Iteration of its Tasks

Tasks inherit and follow Team Iteration field from their parent User Story when User Story and Task are assigned to the same Team Iteration or when Team Iteration field as blank in both of them. In this case, whenever you assign a User Story to some other Team Iteration, same assignment is made for Task automatically. However Tasks can be re-assigned manually to other Team Iteration. Then changes of User Story assignments are no longer reflected in Tasks.

Still have a question?

We're here to help! Just contact our friendly support team

Email us
The more details you can give us the better
Live chat
Prefer instant messaging? Try our live chat
Service Desk
Add tickets, comments and track status in our Helpdesk
Slack Community
Shape the future direction of Targetprocess

Find out more about our APIs, Plugins, Mashups and custom extensions. Join our community of passionate users and even discuss directly with our developers.

Start your free trial

Enter your email
By clicking "Continue", you acknowledge and agree that we will process your personal data in accordance with our Service Privacy Policy and Terms of Service.

We’ve sent you a confirmation e-mail — please, go check it.

Or get a live
product demo