Showing results for 
Search instead for 
Do you mean 

How Live Planning Works - An Introduction

by Dreamer on ‎07-06-2007 07:46 PM

In this months blog I would like to spend some time on how polarion’s liveplan feature works. Knowing this will help you to understand why polarion is organizing and planning items just the way it does. Additionally I will briefly discuss how a planning process in polarion could look like.

Important fields

Let us first discuss the most important fields that have an impact on the plan


Setting an assignee will make the workitem appear in the row of the assignee in the liveplan. If an item has no assignee it will appear in the project row at the bottom ofthe plan.



The higher you set the priority of a workitem the more left it will appear in the liveplan and the earlier the assignee should start his work on it. Priority of an item has no impact to the color of an item in the plan. The color of the item visualizes its severity.

Remaining Estimate

The length of the bar in the liveplan represents the remaining estimate. If an item has no value in the remaining estimate it will appear in the plan with an effort of 1 day. The remaining estimate is set automatically to the same value that you specify in the initial estimate field. This makes sense as when you estimate items the first time remaining time and estimated time should be the same (no work has been done yet on it). Once people record their work on a workitem the remaining time will decrease or hopefully not increase (this might happen when we made too optimistic estimates).


A timepoint represents a deadline or milestone in your project. Timepoints represent iterations inside your project. In agile projects you may have an iteration every two weeks in which you deliver a set of items (features). Timepoints also act as stages in your project. Example are: „Feature Freeze“, „QA“, „Ready to Market“.


We will cover this topic in more detail in the next blog on planning. For now let us only say that you can set dependency links that control when an item is planned in context of other items. You may express for example by a dependency link that a task can only start when another task has been finished.

Iterative Planning

In the next section I want to give you a basic overview on how a planning process with polarion could look like. Please keep in mind that this is more a guideline than a checklist to be followed step by step.

Initial Plan

Lets take a straight forward approach with 4 planning phases

  1. Define timepoints of your project (milestones)
  2. Estimate and assign work items to milestones/timepoints
  3. Define Assignees and let them create or review your current estimates
  4. Detailed planning by using priorities

Define timepoints of your project (milestones)

We will need administrative rights inside our project to define timepoints. In our example a timepoint represents an iteration.


Estimate and assign work items to milestones/timepoints

Before we start with more detailed planning we will create iteration packages. We achieve this by assigning features to the different release/iteration timepoints. At this point you should have already a basic understanding of the effort needed by each workitem. Add you effort estimation in the „initial estimate“ field.


In polarion we have different ways to assign the estimated work items to releases. I find the multiedit view most comfortable for it.


Below you can see a screenshot of a liveplan with defined timepoints (Iteration 1, Iteration 2, Iteration 3). Don’t get confused by some items being highlighted in red. The workitems have no assignees yet and are therefore qued one after another


Define Assignees and let them create or review your current estimates

Now it is time to define who in your team will have to implement what features. We set the assignees in the workitem field accordingly. The assignee will review the initial estimates and makes adjustments..

When we update the liveplan we will get immediate feedback weather our workitems all fit in our intended schedule. If this is not the case we have to move some workitems to a different timepoint or to shift the whole timepoint.


Grey items in the plan represent workitem assignments from other projects.

Detailed planning by using priorities

Even if all workitems should be resolved at the end of the timepoint we want to influence which items should be adressed first. By setting priorities we can move more important items before less important items. If we have a lot of items with the same priority – „all is high prio“- we can start fine tunining by adding floating values in the priority field. The higher the number the more left the item will appear in the plan.

Best Wishes Tim