LivePlan – Links and Their Impact on Plans
Friday, December 7th, 2007In 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.
In Polarion we can find three categories of links; dependency links, parent links, information links.
Dependency Links (depends on)
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.
Lets have a look at our plan before we will create a dependency relationship.
In this example we will assume that work on “feature 4” can’t start before “feature 1” has been finished. Currently our plan does not reflect that constraint. To achieve this behaviour we have to create a dependency link from “feature 4” to “feature 1”. We edit “feature 4” and add in the field linked workitems “feature 1”. As relationship we select “depends on”. 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.
We will manually update the plan to see what has changed. As expected “feature 4” has moved now a bit to the right as it has to wait for “feature 2” to be finished. Unfortunately “feature 4” is now also in delay due to the shift by the created dependency
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 “depends on” relationship exist between the items. They use the link more to influence the order in which the items are planned. Don’t do this – use priorities instead
Parent Links (parent, implements)
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: “feature 4a” and “feature 4b”. After refining the feature and describing it in more detail you add new estimates to “feature 4a” and “feaeture 4b”. No imagine that you estimate for “feature 4a” an estimate of 6 days and to “feature 4b” 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.
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.
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.
In our example “feature 4a” is in delay and therefore “feature 4” is in delay. If the entry in the timePoint column is in red color it is in delay. “Feature 4” can only be finished at 24th of April which is exactly 4 days later than initially planned.
Information Links (relates to, duplicates, reveals)
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. 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.
Best Wishes
Tim
