Polarion Software Weblog

Polarion 3.0.3 Release is out. The new release ships with a hidden but quite interesting improvement of its wiki functionality.
The feature is called “embedding of workitems inside wiki pages”. Instead of simple references you can directly display workitems inside your wiki pages.

In this blog I want to give you some examples how this functionality can come very handy inside your projects.
Just by embedding simple workitem queries in your wiki pages you will be able to create custom specification documents, impact reports or project status reports.

Lets have a look at the different ways how work items can be embedded.

Embedding via Workitem ID

Use this if you want to embed exactly one workitem inside your wiki page.
Wiki syntax:
{wi: ProjectName/WorkItemId | List of Fields | expand=yes/no}

ProjectName(optional): name of project where work item is located. If no one is specified current project name used by default
WorkItemId: identifier of work item.
fields = List of Fields(optional): list of entries in form FieldName as Type that specifies fields to output. Type can be text, image, image-text. By default the application outputs following fields: id as text, type as image, status as image, severity as image.
expand: if this property is set to yes all specified information about work item is presented below the link

Example:
{wi: MyProject/WI-245 | description as text, status as text-image, severity as text | expand = no}

Embedding By Query

Use this if you want to add multiple items inside your wiki page.
The syntax text is similiar to Polarion Query builder syntax
{wi: query=Polarion Query | List of Fields | sortby = Field tablewidth=Width | tableheight = Height | expand=yes/no}

Example:
{wi: query= type:defect AND (priority:critical OR priority:major) | sortby=created | fields = ID, status as image, severity as image-text, description as text | tablewidth=90% | tableheight=240px}

Creation of custom specification documents

In many cases specification documents consist of some static sections and sections in which you list requirements.

In following Example I combined both approaches - embedding via workitem ID and embedding by query - to create a simple specification document

After some static section at the beginning we list the description of workitem DEMO-1.
Using list as output format( output=list) will display all selected fields below the workitem. I prefer that format because I find it easier to read.
Expand is set to yes (expand=yes) so all listed fields (here only description) are expanded already when you open the wiki page.
We could add additional fields inside the fields section seperated by comma (fields = title as text, description as text…)

In the next section I have added multiple items by query. We have two options here. We can specify a query to filter for specific requirements to be displayed..
For example we could query for all functional requirements with following query: categories.id:functional or
for all requirements in status proposed with following query: status:proposed.
The other option is to pick a set of items by id inside our query.
I have chosen the latter approach in our example.

Displaying linked testcases to a requirement in a table view

You can easily query for linked testcases to a requirement if you know the id(s) of the requirement.
Lets say our requirement has the id DEMO-22 and we want to find all testcases linked to it.
To display requirement DEMO-22 we simply embed it by ID. To display linked testcases in the next column we use following trick.
All linked testcases will have a link to DEMO-22. So if we don’t search by id (id:DEMO-22) but just for the word DEMO-22 we will find all items with the word DEMO-22 inside

.
All testcases that link to DEMO-22 will have the word inside the linked work items section.
As we want to list testcases only the complete query will look like this: “type:testcase AND DEMO-22″

Creating Backlog Reports by User

If you want to embed all open items per user for a specific timpoint you can do that simply by following query:
status:open AND timePoint.id:Iter1 AND assignee.id:ron

Manage Project reports

Create a wiki page that displays items of type project report. The project report item contains personal judgement of the project manager about his project
In that way you can aggregate reports of different projects within one wiki page

Manage risks

Some requirements should be controlled via risks that are assigned to users for periodical review.
Create a risk page which embeds the risks sorted by different aspects

I hope the different scenarios gave you some ideas how that feature could be applied within your project.
Think about: News pages, project announcements, testplan reports, release notes, glossaries
Stay tuned for upcoming blogs.

Best
Tim

Sometimes people ask me how it is possible to track status of items that have been refined by subitems. Imagine having a change request that has been broken down into several tasks. In the following blog I want to take a deeper look on how parent items can be tracked even if they have been refined into subitems.

Where Planning Information is Visible

Each workitem in Polarion contains a field that represents automatically calculated planning information. This field is called planned to. It contains the start and end date to which a workitem was scheduled by Polarion during the latest planning round (update of liveplan). The planned to field is not editable and it will only be updated if the workitem is considered as an element that must be planned (please refer to the planning.xml file for more information).

As soon as Polarion has finished a planning round you will see a start and end date inside the planned to field.

How is the planned to field calculated ?

Please have a look at the other blogs on planning and linking to get a better understanding of Polarion’s planning algorithm. Today we want to analyze the parent/child relationship in more detail. Let’s take following scenario:

Our project has received a change request (EDEMO-1: “Text should be easier to read”) which has as remaining estimate of 10 days and was scheduled to timepoint Rel-1.

After a while our change request has been refined by two subtasks (EDEMO-2: “Increase text size” and EDEMO-3: “Increase contrast and color (black and white)” ) EDEMO-2 has remaining estimate of 6 days and EDEMO-3 has a remaining estimate of 7 days

Parent Items are not Visualized in Liveplan

As a matter of fact we have created a little conflict here. The child items have in sum a different estimate compared to the parent item - 13 days for the child tasks compared to 10 days initially planned for the change request. Polarion’s liveplan will manage such conflicts in following way. Parent items will be removed from liveplan when they have child items. Only child items will be visible. The reason is that remaining time estimates on child items are considered more accurate as estimates on parent items.

How Planning Information is Delegated to Parent Items

So how can we track our change request when it is not anymore displayed in liveplan and how is the conflict resolved?

Even if parent items are not visible in liveplan the planned to field is updated correctly. After Polarion’s next planning round the liveplan will contain a range of 13 days (EDEMO-2 + EDEMO-3) instead of 10 days. Polarion sums up remaining estimates of all child items and presents the result inside the planned to field of the parent item

Where Can I See Planning Information of Parent Items

If you want to see if parent items are delayed you can switch to one of the following views:

• table view,
• tree view or
• roadmap view.

You should make sure that the timePoint, plannedStart and plannedEnd columns are displayed. If an item is delayed it will be marked in red. If you want to check why an item is delayed you can change to tree view and analyze state and estimations of the child items. In our example the 13 days for change request EDEMO-1 is too long and timepoint Rel-1 can not be reached. Additionally we see that task EDEMO-2 can not be finished in time.

Best Wishes
Tim

In this blog I would like to finish the discussion on fields that have an impact on how items are planned in Polarion’s liveplan.
So let’s have a look at the fields we have not covered yet.

Due Date

The due date field represents the same idea as a timepoint. Due dates can be set additionally to or instead of a timepoint. Setting a due date to an item will highlight the item with a red border in the liveplan once it has slipped over the due date. You can use due dates to control important items within your plan. Maybe all items have to be finished at the end of iteration 1 but some items - those that you consider as critical - should be finished at an earlier date.

Planning Constraint

If you set a planning constraint to an item it will always be planned according to the constraint you have set - independently of its priority or dependencies to other items. That means if you set a planning constraint you should know what you do as you overrule Polarion’s planning algorithm.

In the following example “Feature 1” depends on “Feature 2”. We have set a planning constraint for “Feature 1”. It must start on 15^th of August. The planning algorythm has been overruled and the item is planned to the ^15th of August. The existing dependency to “Feature 2” is ignored.

So use planning constraints with care. In some situation however planning constraints come quite handy. For example defining holidays or adding fixed events to the plan (exhibition, fair…)

Time Spent/Work Record

This field has only indirect impact on our plan as it updates the “remaining estimate” field. Whenever somebody enters some value either in the time spent field or as a work record the remaining estimate will be reduced by the entered value.

If you want to benefit of the advanced time reporting features of polarion you should use work records instead of time spent field. Work records are user specific compared to time spent which is an anonymous entry.

Planned To

I added this field only for completeness as it can not be changed by the user. The “planned to” field displays the result of Polarion’s replanning. Whenever the liveplan is updated Polarion changes the content of the field to the updated time frame to which the item was scheduled. If you want to visualize this field in the table you have to add “plannedStart” and “plannedEnd” as columns.

Resolution

The resolution field has a simple but important impact on the plan. By default only unresolved items are displayed in the plan. Whenever you resolve an item it will disappear from your plan.

Best Wishes
Tim

One problem of many plans is that they become outdated as soon as you are confronted with changes inside your project. What I like about Polarion is that you can embrace change. Change happens and change is good. Better to adjust the product and face the impact of changes than delivering the wrong product. The main difference to the initial planning process is that we have already an existing plan into which we have to squeeze in new features, bugs and change requests.

In our example we have a simple three step process:

1. Change request/bug arrives and is reviewed
2. Analyze impact, estimate, prioritize and assign
3. Reschedule according to new situation

Change request/bug arrives and is reviewed

As long as the change request has no assignee it will appear at the bottom of the plan. We could interpret the bottom bar as a representation of the project’s backlog à all open issues qued one after another

Analyze impact, estimate, prioritize and assign

We analyze the impact and decide to implement the change. This step requires to set an assignee, priority, estimate and a timepoint to define when the change should be implemented. If it is a bug that has to be implemented at once we give it highest priority.

This information will be enough for polarion to update the plan - now including the new bug. According to the priorities we have set it will appear as first item to be implemented. Unfortunately this has an impact on our plan. We see that some of the features (marked in red) will be delayed.

Reschedule according to new situation

Now it is time to adjust our plan according to the new situation. We may react in two ways. One possibility is to move the milestones that are affected.

The other option we have is to keep our milestone but reassign some other items that won’t make to the milestone because of the unexpected bugfix.

Managing changes in your project will happen quite regularily. But as you can see above it is not complex. The important thing is that you have to keep control on the impact of a change. The liveplan of polarion will help you to control your changes as you will get an up-to-date information on what is going on in your project.

Best Wishes
Tim

This new feature of Polarion 2.6.5 lets users to store important process information: the dates when work items change their workflow status. This information is always available in Polarion, but now we have the opportunity to easily use this data.

For example Polarion users can export status change dates to MS Word documents to highlight the evidence, important for quality processes, of the acceptance of work items (i.e. Requirement or Problem Report). Or we can export such information in MS Excel sheets and use it to audit/measure the time performances of some activities (i.e. how much time elapsed between creating a bug and fixing it).

How it works

The status change dates will be stored in specific custom field(s) of each individual item. So, first of all we have to define the custom fields where we would have dates stored.

For example, we are working on Defect item type and we would like to store the resolution dates.

Custom field definition:

Administration perspective: [select project] : Work Items > Custom Fields topic

Download the defect-custom-fields.xml file and add the following element:

<field id="resolutionDate"
type="date-time”
name=”Resolution Date”
description=”"/>

Upload the modified configuration file back to Polarion. Then we can go on to define the workflow for the Defect item type

Workflow definition:

Using the Web Interface in the Administration Perspective choose topic Work Items/Workflow and create a new workflow definition specific for the Defect Work Item Type (click Create in the Actions column).

Find the Actions table and for action to resolve click on the icon in the last column on right side (labeled Actions).

Now we should have a new pop-up dialog like this one:

In the Function dropdown menu select the FieldValueChange option and click the plus icon and then the again.
Now we have the Parameters dialog where we have to specify following values:

So after closing the two dialogs and saving changes on the main workflow design page we should have the new workflow definition configuration file defect-workflow.xml

Here the fragment of the file with the new function defined:

    <functions>
        <function name="FieldValueChange">
            <param name="field.name" value="resolutionDate"/>
            <param name="field.value.type" value="current.date"/>
        </function>
    </functions>

Now clear the system caches (Administration : Repository, Topic: System > Caches ) and go to try the result of your work!

Note that this new feature is a nice and generic function that we can find implemented out of the box; now, in Polarion 2.6.5, you can also design and implement your own custom functions that could be invoked during workflow transitions!

Custom code invocation in workflow transitions is a very advanced topic, and if you like, we will write some notes on that here on this blog!

In this part of the article we have seen how to record workflow status changes, in the second part we will show how to use these data. Stay tuned.