Understanding ranking in Rational Team Concert 4.0

Planning Component Team, IBM
Last updated: August 6, 2012
Build basis: Rational Team Concert 4.0

Ranking helps you organize and prioritize work items. In Rational Team Concert (RTC), the Priority attribute is configured out of the box as the ranking attribute which means all work items are ranked based on their priority. For all the examples below, we use a project based on the Scrum template. Initially, all priorities are unassigned and the ranking order is based on the id of the work item (which is to say the order in which they were created).


Let’s say we set High priority for Design and Requirements, Medium for Maintenance and Implementation and Low for Testing and Other. Note that the items are not yet ranked. As each item is given a priority, it ‘loses’ its previous ranking (if you change the priority to a different value, you lose the rank held previously).


Now, in order to associate ranks with these newly prioritized items, we need to drag and drop them to their appropriate relative positions. For the example below we have ordered tasks to rank the items. This sets an internal ranking order based on the user’s ordering. The rank setting works similarly if the position of the work item is not changed as a result of the drag, i.e., you drag and drop the work item to the same location.


Gotcha: Dragging and dropping betwen two bands

It’s interesting to note the way the system assigns priorities while dragging and dropping items if you drop in between groupings, e.g., you drop it in between High and Medium priority items, it acquires the priority closest to its initial value when there is ambiguity. So a Low item dropped between High/Medium gets Medium, while a High dropped between Medium/Low (also) gets Medium.

The two figures show how this works where Maintenance is moved upwards below Implementation (it gets a Medium priority) and Implementation is moved downwards below Testing (it gets a Medium priority). Note that the the previous screenshot is used as a point of reference for the screen captures below.


Let’s now assume that Design is a similarly important task compared to Requirements or Implementation. This means that the Design item should have a High priority as well. Therefore we drag the Design work item between the Requirements and Implementation items and observe two things;

• The priority of the Design item automatically changes to High (to match its surrounding items).
• As the Design item is moved now, the system understand that the ranks need to change as well and automatically updates all ranks including and below Design to reflect the move.

As a similar exercise, let’s move the Other in between the High and Medium bracket (below the Implementation task) to see how the rank and priority are applied. We can see from the screen below that it changes the priority from Low to Medium and updates the ranks of the group set. Also, now if we move Other back to the bottom of the pile, it gets reverted to its previous priority and rank.

Ranking in RTC uses stack based ranking

In stack based ranking, the weight of the enumeration (ranking attribute) literal gets higher precedence over whether the item itself is ranked or not. For example, priority is used as a ranking attribute by default. It has three literals namely High, Medium and Low (the weight of these literals is governed by the order in which they are defined in the enumeration). Each of these literals can be interpreted as a separate stack. This means that all high, medium and low items are evaluated as separate entities.

The example attached below explains this more clearly. We can see that there are multiple work items with varying priority. However, not all of the items are ranked. In spite of this, we see that the unranked High items are placed higher than a ranked Medium item. Similarly, unranked Medium items are placed higher than ranked Low items. This indicates that in spite of the rank numbers associated with the work items, the system takes into account the stack which they belong to which means they are placed higher if they belong to a higher stack followed by the next higher stack and so on.

Ranking stability across plans

In a typical scenario, we have stories/epics in the Product Backlog which are then moved to an iteration. The following examples show how ranking provides stability across all these plans such that the ranking is consistent while moving the items across these plans.

Let us first consider a product backlog which has some items which are prioritized and ranked.


We could plan those items for a release. The ranking however is maintained and the items appear in the same ranked order in the release backlog as they were in the product backlog as shown below.


Now we break the story into execution items that will be tracked in the iteration as shown below. It can be seen that the new execution items get a rank of 4 and 5 maintaining the original ranking order (Nested execution items show as children of their plan items.).


Once the tasks have been broken down, they are planned for the iteration. We can see from the example below that the iteration plan mirrors the release backlog ranking. Also, items which do not belong to the iteration plan are grayed out but the ranking order is still preserved as shown below.

Using a Custom Ranking Attribute for Planning

If you find yourself thinking that the built-in enumeration for Priority would work better for you if you had a few more values (which are High, Medium, Low and Unassigned), then you can just edit the enumeration and add some more. We can easily get to 5 values, for example, by adding Critical and Unlikely to the collection.

Expanding Priority

Using the RTC web UI, navigate to the Project Area Editor, select Work Items and Enumerations and add the 2 new values. Be sure to add them in the correct ‘priority’ position relative to the other items – or things won’t sort right (if you forget to do this, you can re-order them using the Eclipse client):


Save the project area (you’ll need sufficient permissions to do that). Then open your plan and change the priority of some of your items:


If you just need a bit more granularity than comes out of the box, you’re done and can get back to work.

Creating and Configuring a Custom Ranking Attribute

A restriction for your Ranking Attribute is that it must be an enumeration. If you want 100 different levels, it will take some time to do that. Maybe, some day, there will be an exposed Rank attribute that is a simple integer and you can pick any value you want, but for now you can specify any values you want in your custom enumeration.

For this example, the new attribute will be called ‘Business Value’ and will hold a collection of decreasingly important values defined by the marketing department (from highest to lowest): Disruptive, Mind-blowing, Game-changing, Unbelievable, Astonishing, and High. The default will be High. [The marketing department has never come up with an idea they didn’t love.]

Start by opening the Project Area Editor and adding a new enumeration with the name ‘Business Value’. We’ll store it in the Process Specification so they can’t keep adding superlatives to it:


For now, we’ll reuse the existing icons, but you could provide your own. Here’s our new enumeration all defined:


Now we need to:

• wire up our new enumeration as an attribute on the Story work item,
• add it to appropriate Editor Presentations for Stories, and
• replace Priority with Business Value on the Ranking View of the Release Backlog Plan.

[For brevity, we won’t add it to Epics or other plan views, but you certainly could.]

Assuming you know something about custom attributes, I’ll show some screen shots but not walk through all of the steps. You can learn more about adding custom attributes to work items from this article.

 
Now if you have been playing along at home (or done this before), you already realize we can’t do step #3 yet. We added the attribute to Work Items, but Planning doesn’t know about that attribute. So we can’t add it to the Plan View yet. [Go ahead, try it.]

This next step requires using the Eclipse client, as the Project Area Editor in the web UI does not yet handle Planning configuration data. Open the Project Area Editor in the Eclipse UI and go to the Configuration Data for Planning and Planning Attributes.

To make our new Business Value attribute “visible” to Planning, we need to add it to the Attribute Mapping for Plan Attributes:


Save the changes in the Eclipse UI and return to editing our Plan View. [You may need to clear the browser cache and refresh the plan to pick up changes made to the Process Specification in the Eclipse client.] Open the Release Backlog, change to the Ranked List view and edit it. Using the Column Display option, add Business Value to the plan view:


If you add some new stories, you’ll notice that they all default to a Business Value of High (which is how we defined it). Here is our Release Backlog with the plan view changes and some new stories:


But even after you change the Business Value setting, the ranking doesn’t change and the items don’t rearranged automatically the way they used to.


We need to go back to the Eclipse client to change the Ranking attribute to be our new Business Value enumeration. You may have noticed this setting was on the same page we did the Attribute Mapping on:


While we’re here, we should fix up some other things, too. [Actually, we really need to do this step or the new ranking won’t quite work.] In order for Business Value to be fully functional in its role as Ranking Attribute (meaning we’ll want to sort and group by it), we need to add it to the appropriate Plan View Elements:


Return to the web client, clear the browser cache and refresh the page, and the items will be sorted by Rank (as they always were) but now Rank is determined by the value of the Business Value attribute:


And we’re done! Your Stories and Release Backlog Plan Ranked List view will now use our new Business Value attribute to determine Story ranking.

Unranking a work item

You can click on the context menu to the left of the item and select the ‘Remove Rank’ option to remove a rank currently assigned to the item. On doing this, the item goes to the bottom of the stack with an ‘Unranked’ value.

Business Value ranking vs. Execution Strategy ordering

Business Value or Priority ranking is for planning which identifies the most important work items so we can make sure that they are the first ones implemented (and means we’re delivering value to our stakeholders as quickly as possible). It’s a product management function.

The Planned Time view on iteration/phase plans is also a way of ordering work items associated with a plan and like Ranked List, also supports drag and drop. Execution strategy ordering is a personal and possibly team-based approach to working efficiently, getting related work done at the same time or prioritizing dependencies so that everyone can get done on time. At this level, all work is similarly important as it is all intended to be completed during the iteration, though for particularly long iterations, the Business Value ranking may inform the appropriate Execution Strategy.

However, there is a difference between the planned time and ranked list views. Typically, work items are assigned to team members as part of a plan. The work items may be ordered for execution based on factors like estimates or other technical dependencies. This can be handled at the Planned Time view level and it mirrors the My Work View of the respective team member.

For additional information about the topic presented in the article add your comments or questions directly in the discussion part, or visit our Jazz.net Forum.

Copyright © 2012 IBM Corporation