Products
Polarion goes Scrum – 2011 (Part 3)
By Nick Entin, VP R&D, Polarion Software
In the second article in this series, I talked about Incremental Iterative Development and the benefits our team derives from it. In this third article o...
By Nick Entin, VP R&D, Polarion Software
In the second article in this series, I talked about Incremental Iterative Development and the benefits our team derives from it. In this third article of my Polarion Goes Scrum series, I’ll be sharing some of the Polarion R&D team’s not-so-secret secrets for configuring Polarion to support the way we work with Scrum. This and further sections of the article assume that the reader knows basic functionality of Polarion ALM, its terminology, and has at least a small experience with the product’s administration interface.
Polarion ALM in Scrum process: Configuration, Work Item types, attributes, links
Please note also that the configurations I refer to are subject to change – we inspect and adapt our processes continuously, which means that by time you read this, we might already have changed some configuration or a process.
We have identified 5 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
- Epic: this type allows us to identify big areas of implementation, which consequently will be divided into concrete User Stories. The difference between Epic and User Story is that you can’t plan an Epic all at once. You need to introduce some incremental process of delivering functionality, butyou still want to group things together as they comprise a single business requirement.
- 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 a test case, install a 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 and Epics. The following figure shows our Work Item type configuration in Polarion ALM:
Let’s check what attributes (custom fields) we defined for these Work Item types.
User Story
Our requirements for User Stories (excluding common requirement for all other requirements):
- 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,
- Responsible developer – this may sound like a 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.
- Status – most important states are: “Open” (new, to do), “In Progress” (there is active work on it), “Implemented” (implementation activities are finished) and “Done”.
- Size in Story Points – this is typically empirical data, which the team agrees on. Size of the User Story is typically estimated during an Estimation Meeting after initial analysis and brainstorming by the team.
- There are further attributes 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.
The most important attribute of UserStory is Acceptance Criteria – sometimes the description of a business demand is too verbose or allows several interpretations, thus different people may assume different results.
An acceptance criterion is separate part of the description, which identifies concrete approach and technical constraints how the story should be implemented. This allows also Testers perform exactly the same scenarios as were supposed in implementation. Customer and Product Owner must agree on the acceptance criteria and it must not change after acceptance.
Epic
The model of Epic doesn’t differ much from that of User Story. However, Epic is supposed to be composed fromtwo or more child User Stories and, for instance, size of Epic is aggregated from size of the children. Thus there is no need to estimate a whole Epic at once.
Typically, the necessity to define an Epic is clear from the beginning – you’ve just described some business requirement, and realize that the acceptance criteria are too complex to be addressed in one step, so you need to split it. However, sometimes it’s not so clear from the beginning. Therefore, at Polarion, we often convert (Change Type) a User Story to an Epic, if incremental implementation in multiple steps is identified as desired.
Improvement
As any implementation-related Work Item, Improvement has references to:
- The build in which 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 repository branch it was committed
- Assignee(s), estimates, etc.
Prioritization of an Improvement is typically done on level of the corresponding User Story. There should be no Improvements planned to a Sprint which are not linked to a User Story.
Defect
Defect is not so different from the attributes of Improvement. However, Defects can be planned toa Sprint without a link to a User Story, and they might be prioritized separately. Most important attributes include:
- 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 an impact it has for 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 cannot be resolved in a release, and should be mentioned in the “Known Issues” list in the release notes.
Task
This type of Work Item doesn’t have direct connection to a 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
While perhaps not quite so important as Work Item types, still Polarion’s Work Item linking capabilities help us a great deal in creating a work breakdown structure and benefitting from the Planning features, which take into consideration various types of links.
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 resolved, the UserStory is not considered Done. Link role “implements” is also applied for linking of UserStories to Epic.
- 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.
- 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: to improve usability of the feature, or a defect is discovered in one item because of the fix of another.
An example of Work Breakdown Structure with our configuration is shown on following screenshot:
Screenshot of work breakdown structure in Polarion’s Scrum configuration of Polarion ALM
In the next article in this series, we’ll take a look at backlogs and how Polarion R&D defines and manages them.
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.
