Polarion goes Scrum (Part 3)

Polarion ALM in Scrum process: Configuration, Work Item types, attributes, links

by Nick Entin, VP Research & Development, Certified ScrumMaster

This and further sections of the document assume that the reader knows basic functionality of Polarion, its terminology, and has at least a small experience with the product’s administration interface.

Please note also that the configurations I refer are subject of change – we inspect and adopt our processes continuously, which means that by time you read this, we might already have changed some configuration or a process.

We have identified 4 major Work Item types as being the most important for our product development:

• User Story: this type of Work Item defines what functionality should be added, updated or removed. It is formulated on business language, has business value, and groups all relevant activities together


• Improvement: this type refers to some changes which will directly appear in the future release. For instance, code improvements, Documentation tasks, etc.


• Defect: I guess, it’s clear what defect is 🙂


• Task: any activity, which requires time, capacities of personnel, but the results don’t directly go to the release. Examples of tasks: write testcase, install demo server, brainstorm discussion about a feature and so on.

In our process, we don’t use Change Requests or Requirements – those are covered by User Stories.

Let’s check what attributes (custom fields) we defined for these Work Item types.

User Story

• Should be possible to identify source of request (whom to ask for clarifications)


• Identify what backlog it belongs to (this would allow us sorting by priority exactly as Backlog Owner wanted)


• Identify relationships between User Stories (from time-to-time people require similar or related functions, possibility to see those relationships simplify prioritization and grouping in the Product Backlog)


• Additional attributes:
  
  
  
  • In our case we want to point out in what edition(s) of our product will gave a feature visible,
  
  
  • Show if a user story doesn’t require documentation,
  
  
  • Track name of customer(s) or prospect(s) who requested the functionality,
  
  
  • etc.
  
  
  
  


• Responsible developer – this may sound as contradiction to a team-oriented approach but there’s a reason for it. In Scrum, when there are several people involved in development of a feature and those groups are changing, if you have a question sometime in the future, you don’t know whom to consult, or who has an overview of all the work related to the subject. We found it practicable to have a single person responsible for each user story, who checks all the activities around it, and who also leads the demonstration of the feature when the product is ready.


• State – most important states are: “Open” (new, to do), “In Progress” (there is active work on it), “Implemented” (implementation activities are finished) and “Done”.


• Initial Estimate – this is typically empirical data, which the team agrees on. The Time Spent and Remaining estimates are calculated automatically by Polarion (inherited fields) from the linked Work Items (Improvements, Defects, Tasks)


• There are further attributes, which are specific to our development cycles (e.g. if the UserStory should be reflected in the release notes or which product line is affected), but for sake of simplicity I don’t list them here.

Improvement

As any implementation-related Work Item, Improvement has references to:

• In which build it was implemented (e.g. testers know which build to take to review this functionality), and correspondingly


• In which build it was reviewed by QA


• In which branch it was committed


• Assigned person, estimates, etc.

Prioritization of Improvement is typically done on level of the corresponding User Story. There should be no Improvements, which are planned to a Sprint, but not linked to a User Story.

Defect

Defect is not so different from the attributes of Improvement. However, Defects can be taken in a Sprint without link to a User Story, and they might be prioritized separately. Most important attributes:

• Build (or Product version) where the problem was discovered (this is string field, because it should allow entering “before version 3.2.1” or “after nightly build Apr 12th 2008”


• Severity – how big impact it has to customers (or internal users)


• Customer (if the defect was reported by a customer, it needs higher attention, also possibly the customer would need a patch for the product, so we need tracking of who should be provided with a patch. Note: other types of Work Items – UserStories and Improvements, – also have this attribute, referring who has requested the function or proposed an Improvement, but it plays a less important role there).


• Build in which the problem was resolved, branches, assignee, estimates and time spent, etc.


• Flag if defect is not resolved, but should be mentioned in “Known Issues” list for the release.

Task

This type of Work Item doesn’t have direct connection to Customer or builds, therefore it doesn’t have any specific attributes. This item also must be linked to a User Story to be selected for a Sprint.

Linking of Work Items

Perhaps not quite so important as Work Item types, still Polarion;s Work Item linking capabilities help us a great deal in creating work breakdown structure and benefitting from the Planning features, which take in consideration various types of links.

Note: some of the screenshots show functionality that’s still subject to change and not yet available in published versions of Polarion. Stay tuned – those are coming soon 🙂

The most important link types are:

• Implements – this is the relationship of Improvements, Defects and Tasks to the UserStory, unless child items, linked as “implementing” are not resolved, the UserStory is not considered Done.


• Depends on – meaning of the link should be clear from its name – the Work Item cannot not be addressed before the linked item is processed.


• Relates to – there is some relationship between Work Items, however it’s just a hint for developers to take a look and see whether the 2 items can maybe be addressed together, or if the linked item contains additional information important for this one.


• Parent – this is applied between Work Items of the same type. Typically used for decomposition of complex User Stories.


• Follows – from time to time it happens, that some problem is resolved, or new feature is available, and those Items are completely resolved in terms of the request. However further work was identified, which should be done, e.g. to improve usability of the feature, or there is a defect discovered in one item because of the fix of another.

An example of Work Breakdown Structure with our configuration is shown on following screenshot:

Next time…

In my next post we’ll take a look into Polarion’s product backlog and see how we compose and prioritize user stories.

---

Editor’s Note:
Nick Entin is VP for Research & Development at Polarion Software. He oversees the development of all Polarion requirements management, application lifecycle management, and team collaboration software products. He is a member of the Scrum Alliance and a Certified ScrumMaster. You can read his profile at http://www.polarion.com/company/people/index.php.

---