Managing Project Planning

Polarion implements a time-box approach to project planning. It is not necessary to spend time tracking down the progress on tasks and issues and then updating a project planning tool with the latest data. With Polarion, managers and teams concentrate on planning which Work Items will be completed for a specific time point and marking the Work Items accordingly. As Work Items are completed, Polarion keeps track of the project status automatically. Project managers and others can always check the status by querying the system for Work Items resolved for a given Time Point (or other time period), or Work Items still not resolved. Queries can be embedded in wiki pages, making it easy for anyone to check the status any time. This approach works with all Polarion products.

The Live Plan view of the Work Items topic rolls up the latest project status information and presents it as a GANTT style chart. The Live Plan makes it easy to spot over- and under-tasked people, and identify dependencies, potential bottlenecks, and in general understand if the project is on track or at risk.

Setting Up for the Planning Engine

Setting things up so the Live Plan engine can render your project plan actually starts when you create a Project in the Administration interface. At that time you specify the "outer parameters" of the project: the starting and ending dates. The project ending date is not cast in concrete - you can change it any time as the project progresses, extending the project or moving the end date up. These dates are the foundation on which the Live Plan engine builds the project plan.

Another important system configuration that affects project planning is the Working Calendar, which tracks how much overall working time is available. The Working Calendar defines both working and non-working time (weekends, holidays, etc.) A Polarion administrator should configure the global calendar which generally specifies the organization's "normal" work policy: the days and hours when people work, as well as days off for weekends, public and other holidays, etc. The global calendar becomes the default for all new projects. Each user can configure a personal Working Calendar which defines his/her individual work schedule. For example, some people may work only part time. At times, people may work overtime, or take vacation time, or other time off. Between the global calendar, and the aggregate of all individual calendars, the Live Plan knows how much total working time is available, and it takes this into consideration when planning Work Items in a given time frame. For information on configuring the global calendar, see Administrator's Guide: Configuring the Working Calendar. For information on configuring users' individual calendars, see User Guide: Configuring Your Working Calendar.

If you have team members who regularly split their working time between two or more projects, you can have an administrator configure time splitting in their user accounts. This will cause the Live Plan engine to account for the available time in the relevant projects. For more information, see Administrator's Guide: User Management: Configuring User Time-splitting.

Time Points are a key feature for project planning and release management. These are essentially named milestones associated with a date. For example, you might have a Time Point named "Beta 1" that falls on some date prior to the actual end date of the project. If you practice iterative development, you can set up a Time Points for each one of your iterations. Once Time Points are configured for the project, Work Items can be assigned a Time Point. It is then easy to query to see what items are unresolved for any Time Point. The Live Plan engine can plan items according to these milestones and you can see how things look in the GANTT chart for any Time Point. For more information on working with Time Points, see additional info in the User Guide section on the Time Point field. To learn how to configure Time Points, see Administrator's Guide: Configuring Time Points.

With the foregoing configurations in place, you can begin creating Work Items in the project and providing values in the Work Item fields related to planning. These include Priority, Severity, Initial Estimate, Remaining Estimate (estimate of time remaining to complete the item), Due Date, Time Point, Due Date, and Planning Constraint. For more information on these fields, see Setting up Work Items for Live Plan later in this topic.

With Polarion, you don't "build a project plan" in the traditional sense. Rather you concentrate on defining the Work Items that must be completed in the project's time frame, and for the Time Points within that time frame. You enter planning data for each Work Item either as it is created, or later on in planning meetings. Polarion's project planning engine takes care of building the project plan which you and others in the organization can see on line as a GANTT style chart, and optionally export to Microsoft Project. The Live Plan is updated as developers resolve Work Items, or as new Work Items are added and/or estimated, or as time estimates change. The latest state is always available on line. So if you choose the export route, keep in mind that you'll want to do it at regular intervals to keep abreast of the progress.


Once you have the project's Work Items defined and "planned", you can always run queries to see what items are open or resolved for any period of time, even if your Polarion product does not have the Live Plan chart.

"Dummy" Project Planning

Here is a possible approach you could take to setting up for Live Plan, especially with a new project. You can use Polarion with Live Plan to create different "what if" scenarios for the project before deciding on the actual scenario on which to start development.

In this approach, you create Requirements and linked Work Items for implementation, setting planning fields for the latter. But you don't initially assign the Work Items to developers. Rather, you (or your Polarion administrator) can create a set of "dummy" user accounts that parallels the people and roles of your actual development team. As you set up your planning data on Work Items, setting time estimates and planning constraints, you can assign each item to one of the "dummy" users. The end result will be a Live Plan that exactly corresponds to your team. You can look for bottlenecks, under-resourced areas, dependencies, etc. and if you see problems you can go back and adjust planning data on relevant Work Items and review the effect of the changes on the Live Plan.

Once you have a Live Plan that you feel you can begin work on, you go in and assign the Work Items to the appropriate "real" developers. You can do this fairly quickly using the Bulk Edit feature to assign multiple Work Items to one developer in a single operation.

Updating the Live Plan

The Live Plan is rebuilt on the server at scheduled days/times controlled in a default job named Live Plan Chart Refresh. The exact firing of this job is specified as a CRON expression. You can see the currently defined CRON expression in the project's Monitor topic in the Scheduled Jobs section of the page. Your Polarion administrator can change the days/times when the Live Plan is updated (see Administrator's Guide: Configuring the Scheduler).

On-demand Update

You can invoke immediate rebuilding of the Live Plan by clicking the Update button in the Live Plan section of the Dashboard topic of your project.

Keep in mind that rebuilding does place processing loads on the server which could affect performance for all users for the duration of the update. If a project is relatively small, this may not be an issue. For very large projects, you may want to try to invoke the update during times of less demand for server resources.

Conflict resolution in Live Plan

Work Items that are forced to be planned with overlaps are reported in the Monitor. If such Work Items are found, the job fails (with status ERROR), but the Live Plan display is updated anyway.

If cyclic dependencies among Work Items are found, then the planning engine cannot continue, the update job fails and the Live Plan display is not updated.

Understanding Live Plan Scheduling

Before setting planning data and constraints on Work Items, you should understand how Live Plan's scheduling prioritization for Work Items.

  1. Dependencies. Items depended upon by others are scheduled before dependent items.

  2. Priority

  3. Severity

All of the above priorities are calculated per assignee.

Effects of Planning Constraint, Due Date, and Time Point fields

The setting of the Due Date and Planning Constraint fields also impact the Live Plan.

The impact of the Due Date field depends upon the setting of the Due Date Planning option in the global system configuration. The effect of the settings of this option are described in Administrator's Guide:Due Date Planning Option.

The impact of other fields is as follows:

  • Planning Constraint: Enables setting of an overriding start or end date. For more detailed information, see Setting up Work Items for the Live Plan: Planning Constraint.

  • Time Point: If you set Time Point, that is in effect the end date for the item and you do not need to set the End Date constraint. If you do set it, and it falls after the Time Point date, the item will be highlighted in red in the Live Plan visualization, and its detail tool tip will have a red background.

Setting up Work Items for Live Plan

This section covers the fields you may want to set for the Live Plan visualization.


The following discussion about setting fields for planning is applicable whether or not you use a Polarion product with Live Plan. You will always be able to use a query based approach to monitoring project progress, taking advantage of the wiki to embed Work Item queries in pages that reveal the current state of things.


This is an important field for the Live Plan. It sets the severity level of the Work Item, which is the next thing calculated by Live Plan after Priority (see Understanding Live Plan priorities).


This is an important field for the Live Plan. It sets the priority of the item in the pan. Items with higher priority will be planned ahead of items with lower priority, all other factors being equal. (See Understanding Live Plan priorities.)


This field doesn't really affect the Live Plan, but it can be useful when adjusting plans as the project progresses, as it is used in the Project Dashboard's Unresolved items by Category. You will probably find it most convenient to set this field as you are setting planning fields.

Initial Estimate

This is the amount of time you estimate will be needed to implement and close the Work Item. In versions 1.x and 2.x this field does not affect the Live Plan. Managers can set it as a guideline or target for developers. Later versions of Polarion will use this field for automated planning accuracy analysis features.

This field has a specific syntax for specifying time. Click the ? icon next to the field for examples of the syntax. For example "1d" means one day, "1/2h" means one half hour.

Remaining estimate

This is an important field for the Live Plan. The length of the item's bar in the visualization is based on the time specified here. Click the ? icon next to the field for examples of the syntax. For example "1d" means one day, "1/2h" means one half hour.


It is not necessary to set this field in order for a Work Item to be planned and appear in the Live Plan visualization. Assigned items are planned by assignee, and each assignee has a separate row in the Live Plan visualization. Unassigned items appear in a separate row labeled with the Project name. So if, in the initial planning stage, you don't know who will handle the item you can still plan for when it should be handled, and then assign it later.

For more information about assigning Work Items, see Work Item Basics: Assigning Work Items.

Due Date

This field specified the date when the Work Item is due to be finished. If you do not use a Time Point to define the item's completion date, you can set Due Date. The End Date planning constraint(if set) takes precedence over this date in the Live Plan.

Time Point

As mentioned in the Overview, Time Points are named milestones with a date attached. If you set this field, it means that the Work Item is planned to be finished by the date of the specified Time Point. Setting a time point does not preclude also setting an End Date planning constraint (see next section).

Planning Constraint

This field is essentially an override to ensure the position of a Work Item at a particular time in the project plan. One of 2 possible constraints can be set: Start Date or End Date. If the Start Date constraint is set, it overrides other factors such as dependency that would otherwise govern when Live Plan plans the item to start. If the End Date constraint is set, it specifies the actual end date of the item, overriding other fields such as Time Point and Due Date.

For example, consider the following 2 tasks:

  1. TASK_1 Implement Feature X

  2. TASK_2 Document Feature X

Suppose you have a Time Point named "Release". Both the above tasks need to be planned to finish by "Release". But TASK_1 actually must be finished earlier to allow time for documentation before "Release". So you can set the End Date to ensure that TASK_1 is planned to actually finish by the End Date even though it is associated with the "Release" Time Point.

For the field value, you can specify either a date only, or date and time. When time is missing, the task starts at the start of working hours on the specified day or ends at the end of working hours on the specified ending day. If the time is outside the working time of the assignee, the start time is shifted after the non-working period and end time is shifted before the non-working period. (Working hours are determined by the Working Calendar configuration.)

Figure 18.1. Setting Planning Constraints

Setting Planning Constraints

Planning constraint field and popup date picker


You will not see relevant planning results for unassigned and un-estimated Work Items.

Planned items in the Live Plan

When the Planning Constraint and Due Date fields are set, the Work Item spans the defined time period in the Live Plan chart. The popup detail (when you click on the Work Item in the Live Plan chart) includes Planned Start Date and Planned End Date and Remaining Estimate.

Planned To

This is a read only field generated by the Live Plan. It shows the date that Live Plan has scheduled the Work Item to be finished.

Estimating Work Item Duration


You can set values in the following fields with all Polarion product licenses except Polarion Reviewer. The Live Plan is only accessible for users of Polarion ALM and Polarion PRO.

The process of estimating time duration of Work Items can vary according to how your organization prefers to handle it. Estimating the time duration of tasks etc. could, for example, be the responsibility of a manager. Alternatively, each developer might estimate each Work Item as it is assigned to him or her, or perhaps the project lead can make an initial estimate and individual developers review that and adjust the estimate. The process is up to you.

There are two Work Item fields for estimating Work Item duration:

  • Initial Estimate: This is where you can estimate the amount of time needed to resolve the item. It does not impact the Live Plan.

  • Remaining Estimate: This is where you specify how much time remains before the item will be resolved. The Live Plan calculation relies on this field for the duration estimate.

These fields use a specific syntax for specifying an amount of time. Click the ? icon next to the field for examples of the syntax. For example "1d" means one day, "1/2h" means one half hour.

The Time Spent field

This field is not for planning per se. It does not affect the Live Plan. It is where developers can specify the time they actually spend on the Work Item. This can be useful for later review of planning accuracy (features for this are planned for future Polarion versions).

In the course of working on the item, a developer can update this field as appropriate. When updating, the developer can also reduce the Remaining Estimate field by the amount of time spent. This will update the Live Plan, where it is visible to management and thereby eliminate the need for the developer to write up a status or progress report.