{"id":1428,"date":"2007-12-07T17:17:12","date_gmt":"2007-12-08T01:17:12","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/LivePlan-Links-and-Their-Impact-on-Plans\/ba-p\/380581"},"modified":"2026-03-26T05:38:28","modified_gmt":"2026-03-26T09:38:28","slug":"liveplan-links-and-their-impact-on-plans","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/liveplan-links-and-their-impact-on-plans\/","title":{"rendered":"LivePlan \u2013 Links and Their Impact on Plans"},"content":{"rendered":"

In the last blogs we spent quite some time to discuss how you plan items and how you can react on changes in your plan. However we did not use links in our plan. As many items have relationships it is important to understand what impact these relationships can have on your plan.<\/P>
\n

In Polarion we can find three categories of links; dependency links, parent links, information links.<\/P><\/p>\n

Dependency Links (depends on)<\/H2>
\n

As already mentioned in our previous blog you should use this type of link if you want to express that one item can only start when the other item has been finished. Typically you will have that type of relationship between tasks. The link should always point from a task to the task it depends on.<\/EM><\/SPAN><\/P>
\n

Lets have a look at our plan before we will create a dependency relationship.<\/SPAN><\/P>
\n

\"dependencylinks1.jpg\"<\/A>
\n<\/P>
\n

In this example we will assume that work on \u201cfeature 4\u201d can\u2019t start before \u201cfeature 1\u201d has been finished. Currently our plan does not reflect that constraint. To achieve this behaviour we have to create a dependency link from \u201cfeature 4\u201d to \u201cfeature 1\u201d. We edit \u201cfeature 4\u201d and add in the field linked workitems \u201cfeature 1\u201d. As relationship we select \u201cdepends on\u201d. As long as the change is not submitted you will see the workitem id in the title section. After submittion the title will be displayed in the linked workitems section.<\/P>
\n

\"dependencylinks2.jpg\"<\/A><\/P>
\n

We will manually update the plan to see what has changed. As expected \u201cfeature 4\u201d has moved now a bit to the right as it has to wait for \u201cfeature 2\u201d to be finished. Unfortunately \u201cfeature 4\u201d is now also in delay due to the shift by the created dependency<\/P>
\n

\"dependencylinks3.jpg\"<\/A><\/P>
\n

As you can see dependencies are a valuable instrument to adjust and refine your plans. Knowing this people tend to make extensive use of dependency links even if no real \u201cdepends on\u201d relationship exist between the items. They use the link more to influence the order in which the items are planned. Don\u2019t do this – use priorities instead<\/EM><\/P><\/p>\n

Parent Links (parent, implements)<\/H2>
\n

Imagine estimated a feature with an effort of 10 days. To get a better understanding of the feature the assignee breaks id down to two subfeatures: \u201cfeature 4a\u201d and \u201cfeature 4b\u201d. After refining the feature and describing it in more detail you add new estimates to \u201cfeature 4a\u201d and \u201cfeaeture 4b\u201d. No imagine that you estimate for \u201cfeature 4a\u201d an estimate of 6 days and to \u201cfeature 4b\u201d an estimate of 8 days. We have created a conflict in our plan. The high level feature has been estimated with a different value than its refinement.<\/P>
\n

Whenever you use parent links polarion will plan the child items and not the parent item. That means that in our liveplan we will from that point on only see the child items.<\/P>
\n

\"parentlinks.jpg\"<\/A><\/P>
\n

As you can see the liveplan always displays the highest refinement level. Probably you ask yourself now what happens with the estimates of the parent workitem and where can you control the status of the parent element? Whenever we want to have a view on the high level items we can consult the roadmap view which contains all items from a timepoint that you select. Personally I prefer an adjusted treeview in which I can also see why an item is in delay and what child item coused the delay.<\/P>
\n

\"parentlinks2.jpg\"<\/A><\/P>
\n

In our example \u201cfeature 4a\u201d is in delay and therefore \u201cfeature 4\u201d is in delay. If the entry in the timePoint<\/EM> column is in red color it is in delay. \u201cFeature 4\u201d can only be finished at 24th<\/SUP> of April which is exactly 4 days later than initially planned.<\/P><\/p>\n

Information Links (relates to, duplicates, reveals)<\/H2>
\n

Information links are the easiest links related to planning as they have no impact at all. You can create as many information links as you like, they will have not change your plan.<\/EM> Inks are anyhow helpful to describe that some items have relationships to each other that should be taken in account. Examples are: A bug is related to a feature, a testcase reveals a bug, a change request duplicates a change request that exists already in the system.<\/P>
\nBest Wishes
\nTim<\/p>\n","protected":false},"excerpt":{"rendered":"

In the last blogs we spent quite some time to discuss how you plan items and how you can react on changes in your plan. However we did not use links in our plan. As many items have relationships it i…<\/p>\n","protected":false},"author":68985,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[],"industry":[],"product":[],"coauthors":[],"class_list":["post-1428","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1428","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/users\/68985"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/comments?post=1428"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1428\/revisions"}],"predecessor-version":[{"id":1429,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1428\/revisions\/1429"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/media?parent=1428"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/categories?post=1428"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/tags?post=1428"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/industry?post=1428"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/product?post=1428"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/coauthors?post=1428"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}