There are no formal dependencies in agile software development. However, in practice pieces of work are often tied to one another. For example, if the core team is building an API, some or all of the other teams' work may be dependent on the core team's progress. Or, if the infrastructure team is doing technical maintenance, the production team's work is on hold until the maintenance is done. Keeping track of these informal dependencies in your head can be tiresome.

In Targetprocess you can track such dependencies via Relations.

How to add a Relation

You can create a relation for any entity (user story, bug, feature, task, etc.) via the Relations tab in views:

To create a Relation with an existing entity or multiple entities please click on the ‘magnifying glass’(search) button.

To add a new entity and create a relation with it in one step, you can use ‘quick add’ button.

Types of Relations

The relations can be identified as Dependency, Relation, Link, Duplicate or Blocker at your discretion.

  • Blocker does not literally block the flow of entities in a project. That is, you can still change states for an entity with a Blocker. A Blocker could be an issue that has to be resolved before the entity for which you are adding the Blocker relation can be completed. Find more about Blockers and Impediments.
  • Dependency means that a user story/task etc. depends on another user story or task, or any other entity. For example, the core team is working on an API, and the other teams are dependent on the core team's progress.
  • Duplicate relations are especially useful when you work with bugs and requests. There is special Duplicates box in the right panel of the detailed view for every bug and request. It allows you to mark a bug or a request as a duplicate of another one. Once you mark an entity as a duplicate, a relation of the Duplicate type appears, connecting the two entities.
  • Relation and Link are any other ad hoc relations. For example, you’ve created a User Story and a Bug from an incoming Request. All these entities are related to each other, and you can add them as Relations. In basic setups Relation and Link behave the same way. They are aliases and the only difference between them is the icon and label. Which you choose to use for your particular use case is based on your personal preference.

In Advanced setups relations of types Relation and Link may work differently when the Portfolio Management features are activated. These features are now not available for production usage. They are in early preview (alpha) state.

You can set a relation between any entities in Targetprocess, no matter which Project or Team they are assigned to.

Directions of Relations

Relations can be Inbound or Outbound.

  • The Inbound entities should be completed before the current entity is started.
  • The Outbound entities should be started after the current entity is completed.

Sometimes Relations do not have an obvious inbound/outbound direction, which you choose many cases is a matter of personal preference.

Relations always appear in the Relations tab for both of the related entities, either as “inbound” or “outbound”. If User Story1 depends on Bug1, and Bug1 is shown as an inbound relation for User Story1, then you will see the same relation in the Bug view as outbound.

Edit Relations

You can easily remove a relation, if created by mistake. A click on the Unlink button breaks any relation between entities.

Also, the type of a relation can be easily changed.

Access Permissions

To add a new relation or change/remove one, a user must be able to modify both related entities.

If you do not want to include someone to all projects to make relations, you can consider Contributor access that allows setting relations easily.

See also

  • Klari

    If you set a relationship to “Dependency” does it “lock” with the User Story it is dependent upon? In other words, you have 2 User Stories and they both have to be complete before either of them are implemented. Does “Dependency” prevent one to move to the next state (or defined state) before the other one also moves to the same state? An example is you have a User Story to develop a Course and a second User Story to develop a test for that course. We don’t want the course going out to production without a test and we don’t want the test to go to production without the course.

  • Sergey Gnedin

    @disqus_IRl9JLYiia:disqus a quick answer is “No”. Relations in Targetprocess do not block any actions with required items, they are for information mostly. You could set a blocker type of relation so that a special icon appears at user story details to alert you, but that’s it, sorry.

  • Alex

    You have to prevent such ‘dependent’ items from state changes manually so far. I’ve posted this requirement (to let existing Relations lock state changes) to our public backlog and added your votes for it:

  • Damien SALLE

    Why the User Stories listed within a Feature Do not appear as “relations” or “dependencies” of this feature?
    Basically, I’d like to look at the RelationsManagement report and see “how much of the work I have completed” and be able to reset priorities…
    It would be a kind of PERT diagram that we could filter by Epic/project/Release/Iteration etc…
    This kind of PERT/Dependencies is lacking in the Lean approach to my sense…

    Any opinion on that?

  • Alex

    Please note that Relations in Targetprocess may not fit the best way for what you would like to achieve using them. Please keep this in mind when you choose what tool capability to leverage for which purpose. And let me describe recommended usage practices below.

    To represent tight ‘parent-child’ and ‘work-container’ dependencies we recommend using domain model structures designed for this purpose especially. We support progress measurements from bottom to top of this hierarchical stack (for example Task -> Story -> Feature -> Epic -> Project -> Program). For each of the ‘parent’ items you can find current progress indicator (in terms of sum of effort or percentage of complete work) and visualize it.

    In contradiction to this hierarchical layers, Relations are designed to be used to visually represent links between entities that are not involved into progress calculations. They provide additional visibility in terms of requirements, or implementation / delivery order (including work blockers and impediments), so you can build relations map report or 2D card board representing dependencies, but they do not support strict constraints, limits and progress calculations.

    In the meantime, I’ve added your opinion to the corresponding discussion thread in our public backlog (… ) so it will be definitely considered by our UX designers when we decide to improve existing Relations engine and reports.

    And if you still require some assistance or guidance from our side, please contact us directly – our Product specialists will be glad to elaborate the particular solution to address the needs of your explicit workflow.

Still have a question?

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

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