Polarion Software

E-BOOK
Europe, Middle-East, Africa: Polarion Software GmbH
Lautlinger Weg 3 70567 Stuttgart, GERMANY
Tel +49 711 489 9969 - 0
Fax +49 711 489 9969 - 20
www.polarion.com - [email protected]
Americas & Asia-Pacic: Polarion Software, Inc.
406 Tideway Dr. Alameda, CA 94501, USA
Tel +1 877 572 4005 (Toll free)
Fax +1 510 814 9983
www.polarion.com - [email protected]
Polarion goes
SCRUM
Polarion Software

www.polarion.com
Why Scrum?
Today many software companies are switching to Agile process-
es and, particularly to Scrum. Polarion Software also adopted
Scrum for several reasons, some specic to the company (size,
area of business, customers, etc.), and others quite general. This
paper will focus on the major factors that inuenced us.
Perhaps the most important, reason was transparency. Before
Scrum, customers would want something, Product Management
then dened requirements, the development team committed to
fullling them, but the end results were not always as expected.
Delivery sometimes slipped, and if a release was rescheduled,
the risk was unclear and nobody could tell if new date was re-
ally realistic. Also, we needed to be able to respond quickly to
changes in market conditions and business strategy.
Scrum helps us understand what we need to do to build quality
software faster. We switched from dened and predictive de-
velopment to an empirical iterative incremental model - exactly
what Scrum is about.
Scrums Core Values
Lets quickly review some of the important values of Scrum:
Empiricism facilitates management, development and
deployment of complex products
Inspections and Adaptations, allowing people to check
and reach goals
Full Transparency: people know the exact state of the
product. No guessing or relying on statements like were
right on time.
Iterative development generates visible Increments of
functionality. Progress is measured not by time or money
spent, but by concrete results.

Self-organization people want to do their best, and will
consistently achieve this when there is room for them to
work in whatever way is most efcient for them, rather than
according to some dictum. Team Integrity is raised, enhanc-
ing productivity and motivation.
Delivery many great projects with very capable teams
have failed to deliver anything. Scrum helps teams mini-
mize this risks along the way. If a project is in fact going to
fail, its better to know this as soon as possible, kill it earlier,
and cut the losses.
Figure 1
Polarion Software

www.polarion.com
Unlike the old waterfall approach, Scrum recommends a high-
ly-adaptive way of development with short iterations producing
fully tangible results. Major benets Polarion has realized from
Scrum development include:
Shorter time to release to the market
Transparency to management and customers
Faster reaction to market needs and customer condence
in Polarions development
Simpler synchronization of distributed teams
Easier releases smaller stabilization sprints, less things
to test
Faster feedback from the eld
Flexibility in prioritization, risk reduction
Also, some activities may be done in parallel. Specication of
one feature for the next iteration may happen in parallel with
implementation of another feature already specied in a previ-
ous iteration.
We have very short iterations of 2 weeks, with an iteration Plan-
ning Meeting at the beginning, and an iteration Assessment
Meeting the end of each iteration. This has proven optimal for
our several teams of 3 to 10 team members.
Figure 2 inputs for Product Backlog
Polarion ALM in Scrum Process
The remainder of this paper assumes you knows the basic functionality of Polarion, its terminology, and that you have at least some
experience with the administration interface.
We have congured Polarion ALM with 4 work item types to sup-
port our Scrum process:
User Story: denes what functionality should be added,
updated or removed. It is formulated on business language,
has business value, and groups all relevant activities to-
gether.
Work Item Types
Iterative incremental Development
Polarion Software

www.polarion.com
Improvement: specied some change(s) that will appear
in a future release... code improvements, Documentation
tasks, etc.
Defect: I guess its clear what defect is :)
Task: any activity consuming time and human resources,
but the results dont appear directly in products write
a test case, install a demo server, brainstorm discussion
about a feature, etc.
Youll notice we dont use Change Requests or Requirements
those are covered by User Stories.
User Story Attributes
Attributes are reected in Custom Fields we dene for each work
item type. For User Stories we track:
Source of request (whom to ask for clarications)
Backlog it belongs to (for sorting by priority exactly as
Backlog Owner wanted)
Relationships between User Stories (People may require
similar or related things. We need to see those relationships
to simplify prioritization and grouping in the Product Back-
log)
Product edition(s) that will have a feature
Doc not required ag if a User Story doesnt require
documentation,
Who requested the functionality ( customer, prospect, etc.)
Responsible developer this may seem a contradiction
to a team-oriented approach but theres a reason for it. We
found it useful to have a single person responsible for each
user story, who checks all the activities around it, and who
also leads the demos 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 (imple-
mentation activities are nished) 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 ALM (via inherited
elds) from linked child work items (Improvements, Defects,
Tasks).
There are more attributes, specic to our development cy-
cles, but these are the main ones.
Improvement Attributes
As any implementation-related work item, an Improvement has
references to the build in which it was implemented (so testers
know which build o review), in which build it was reviewed by QA,
the branch it was committed to, the assignee, time estimates,
etc.
Prioritization of Improvement is typically done in the correspond-
ing User Story. All Improvements planned to a Sprint should be
linked to a User Story.
Defect Attributes
Attributes are similar to those of Improvement. Defects can be
taken in a sprint without linking to a User Story, and they may be
prioritized separately. Most important attributes include:
Build (or Product version) where the problem was discov-
ered
1
Severity the impact on customers or internal users
Customer if reported by a customer, it needs higher
priority. Also, the customer might need a patch, so we have
to track who should be provided with one.
2
Build in which the problem was resolved, branches, as-
signee, estimates and time spent, etc.
Known Issue defect is not resolved and should be men-
tioned in Known Issues list for the release.
Figure 3 Work Item type conguration in Polarion ALM
Polarion Software

www.polarion.com
Task Attributes
This type of work item doesnt have direct connection to Cus-
tomer or builds, therefore it doesnt have any specic attributes.
This item also must be linked to a User Story to be selected for
a Sprint.
Linking of Work Items
Perhaps less important than work item types, still Polarions link-
ing capabilities help us in creating work breakdown structure,
and we benet from the Planning features, which take in consid-
eration various types of links.
The most important link types are:
Implements: the relationship of Improvements, Defects
and Tasks to the User Story. Until linked child items are re-
solved, the User Story is not considered Done.
Depends on: meaning should be clear from the name the
linked item must be processed rst.
Relates to: ags some relationship between work items;
just a hint for developers to review if there is anything rel-
evant or important in the linked item.
Parent: links work items of the same type. Used for decom-
position of complex User Stories.
Follows: Some work Items may be resolved in terms of the
request, but it turns out they need further work: usability
improvement, or a defect resulting from a x of another.
Figure 4 Example of Work Breakdown Structure with our conguration
Polarion Software

www.polarion.com
Product Backlog
Typically the Product Owner writes up items for the Product Backlog in a Word or Excel document and then simply reshufes them
according priority. This approach could easily cause all kinds of problems except for the fact that Polarion ALM enables efcient and
coordinated management of such artifacts.
Composing User Stories
Across all owners and stakeholders, we use 3 ways of compos-
ing User Stories:
Through Polarion Web UI (Create Work Item)
Through Email sent to the Polarion Maillet
Through LiveDocs, Polarions exclusive ofce document
synchronization feature.
Regardless of the authoring method, created work items appear
in the Tracker and its relatively easy for all stakeholders to nd
them using Polarions Query Builder. (Such a query might be
type:userstory AND backlog:usability). We often embed
queries into Wiki pages so stakeholders dont have to formulate
queries. The one shown in Figure 6 below collects all backlogs
and displays the top items.
Prioritizing of User Stories
Here our process differs from typical Scrum. We have several
relatively independent stakeholders, all committed to common
goal, but still in pursuit their own targets (sound familiar?) There-
fore, each backlog is prioritized separately by the backlog Owner,
who denes the threshold of his or her items to ag those which
must appear in the Product Backlog and, ideally, should be dis-
cussed by the team.
Figure 5 A Stakeholder Backlog
Polarion Software

www.polarion.com
Our next step is to collect all the required items for the Product
Backlog. In Polarion ALM, its quite easy to create a Wiki page
which collects all the top (i.e. highest priority) items from vari-
ous backlogs we just embed an instance of the {workitems}
macro, supplying correct query to fetch items from the backlogs
maintained in the Tracker.
Next, the Product Owner prioritizes the list.
Weve dened a custom integer eld Prod-
uct Backlog Priority (PBP)which the Product
Owner uses to sort the items accordingly.
3
NOTE: A highly useful Polarion feature lets
you click More in a backlog table embed-
ded in a Wiki page, which opens the Work
Items table in the Tracker (a prime example of
Polarions integrated approach to tools).
Extracting from Stakeholder Backlogs to Product Backlog
Figure 6 Backlogs wiki page with embedded queries displaying top items different backlogs
Figure 7 Tracker items comprising the Product Backlog displayed in a Wiki page
Polarion Software

www.polarion.com
The PBP attribute also helps to track down if there were some
changes in a particular backlog that are not yet reected in the
Common one. For example, a query that retrieves all the impor-
tant User Stories which dont have the PBP eld set:
We actively use Polarions Auto-assignment feature when creat-
ing new work items. This enables immediate assignment to a
Senior Developer, who will potentially lead the implementation.
This developer gets an email notication and sees the new item
assigned to him. This encourages early review of posted user
stories, provides read-ltered input for the planning meetings,
etc.
To simplify prioritization the weight or initial estimate of a
User Story is important, and automatic assignment helps to get
initial review and communication going even before the planning
meeting.
Also, weve congured the User Story work item type to ag-
gregate the values of Remaining Estimate elds from any child
items.
So by brainstorming, and reaching agreement at the Planning
Meeting, we identify an Initial Estimate value for each User Story.
Later however, when it is decomposed into to Improvements,
Tasks and Defects, we can often spot variations that particular
work actually takes less time, or some additional task was not
anticipated, and was discovered after implementation began.
This data is extremely helpful for re-planning of any User Story
that was not nished to then next Sprint.
Additional tips from our development process
Tips
Use Auto-assignment for new work items
Congure the User Story work item type to aggregate the
values of Remaining Estimate elds from any child items
Figure 8 Wiki page section with query for potentially missing backlog entries
The Sprint: Meetings
Meetings are possibly the most important assets of Scrum.
Meetings are when the team commits to the Product Owner
on the amount of work (features) they will address over each
sprint. They discuss the progress in Daily Scrums and, nally,
access results at the last meeting. In this section and the next,
Ill describe how we manage those meetings with the Polarion
development team.
The Planning Meeting
The goal of the Planning Meeting is to ensure that the team fully
understands the Product Backlog items, to commit the team to
implementing agreed-on items in upcoming sprint, and to en-
sure proper distribution of work among team members. During
the Planning Meeting dependencies between teams are also
identied to allow as much parallel work by the teams as pos-
sible, keeping the same focus for the iteration.
The planning entity for the sprint is the User Story. Each one has
a customer (the person who formulated the requirement) and an
owner typically a Senior Developer, who then follows the User
Story through the full lifecycle.
Polarion Software

www.polarion.com
Typically the meeting is split to two parts. The rst part involves
the Product Owner, and possibly other stakeholders, to ensure
common understanding of things to be done and commit the
team to some work items.
The second part is a rather internal meeting, where the team
decides who will implement what and splits the User Stories into
concrete Task and Improvement work items, validating capacity
of the team using the Polarion ALMs LivePlan feature.
4
Normally the User Stories in the Product Backlog have been
inspected and time-estimated by developers in advance. Team
members come prepared with questions, and perhaps concerns
about conict with some agreements or principles, or inconsis-
tencies.
Out of the Planning Meeting come the User Stories selected for
the sprint, which becomes a Time Point assignment in Polarion
ALM. Results of the planning meeting are presented in a special
wiki page showing the agreed-upon Sprint Backlog:
Figure 9 Sprint Backlog in the integrated wiki
Slipping User Stories
We pay special attention to User Stories committed to a Sprint,
but not completed. Its very natural to slip to the next Sprint be-
cause its just taking a little longer.
One expects that as soon its moved to next Sprint, it will be
done on the rst day. No! Experience shows that developers of-
ten leave unnished User Stories to end of iteration because they

are easy to complete. But in reality - they get behind with other
tasks, and the slipped User Story remains unnished and slips
even further into next Sprint.
A burning question in our Planning Meetings is: If this User Story
was not addressed on last Sprint, how can we ensure that our
new commitment to this User Story will actually be realized?
Polarion Software

www.polarion.com
Daily Scrums might be the most complicated part of Scrum be-
cause it requires changing perceptions. Too many of us inter-
pret meetings as means of getting tasks and reporting back, but
Scrum in general, and Daily Scrums particular, are about helping
the team to understand the current situation and to adjust if nec-
essary. Daily Scrums let team members to synchronize and all
can check whether sprint goals are still feasible and if not, take
decisions about what to change. No reports are made, and the
Scrum Master poses one simple question: Are we sure well
meet our Sprint Goals? Please show/explain how we do that!
We use the Wiki Task Board to track progress of our sprint ex-
ecution. :
5
Figure 10 Task Board in the wiki
Daily Scrums
Since our teams are small and we ad-
just daily Scrums to the lunch hour :).
When the most important questions are
answered the team may go to lunch and
discuss very low level details, if needed.
Polarion Software

www.polarion.com
Every iteration ends with an Assessment Meeting, where every
developer presents his/her work, either as a document (if the
task was to specify , etc.), or as a demo of the implementation
in the product. Each User Story should already have been tested
by QA.
6
For the Assessment Meetings we check only those items marked
as Done.
7
As input for the Assessment meeting we use yet
another, more compressed, variant of the Task Board:
The end part of the Assessment Meeting is for introspection
and Lessons Learned. Ideally, it is a time to discuss how we
could optimize the process to implement more over a sprint, but
typically we nd ourselves trying to identify things that were less
than perfect in our process and/or the implementation of some
feature implemented in the sprint. We also try to identify addi-
tional synchronization risks, problems of communication, involve
additional people to show them our dependency, which was not
fullled, and other subjects.
The Assessment Meeting
Figure 11 Task Board Summary on the Wiki
Polarion Software

www.polarion.com
The Sprint: Development
During a sprint, the development team continuously integrates
all changes, and updated versions of the product are installed
on the internal servers daily to prove stability and allow earlier
testing of new functionality by other people (testers, doc writers,
etc.)
Every developer should know his/her personal plan, which
matches the team plan set during the planning meeting. Devel-
opers track tasks via
Personal queries, like assigned to me in current TimePoint
E-mail notications of newly assigned work items
The LivePlan chart and corresponding Wiki pages in our Po-
larion system
Burn-Down Charts
We congure the LivePlan view to show only entities assigned to
a TimePoint (usually the current sprint). It shows only leaves of
the work item work-break structure (i.e. it doesnt render User
Stories on the plan if it has child items improvements, tasks
or defects).
The LivePlan also reects all non-working days (congured in
the global working calendar), and personal days off (congured
in developers personal working calendars). We get very clear
information whether or not the Sprint goals are still achievable
in the sprint time frame. The plan is ordered by priorities and se-
verities in the way developers have agreed upon in the Planning
Meeting (part 2) . Correspondingly, less important items should
be at the end of the plan. We also have Wiki pages that highlight
the progress of the team and remaining time:
Figure 12 Burn-down chart in the Live Plan
Polarion Software

www.polarion.com
Polarions Road Map view also gives a clear picture of the work items in tabular form:
Figure 13 Remaining time estimate in the Wiki
Figure 14 Polarion ALM Roadmap View
As implementation enters the Implemented state, it should be
taken over to QA and Documentation. There is automatic testing
through unit tests and so on, but every feature should pass QA
control to ensure consistency of the implementation, acceptable
levels of usability, that licensing and conguration for different
product lines is correctly implemented m and common user ac-
ceptance.
Typically QA and Documentation starts in parallel with devel-
opment based on a specication document (normally a wiki
page). Final denition of the test cases and documentation typi-
cally happens at the point where implementation is really consid-
ered done, and rst round of review (also by QA) is passed.
8
The
User Story is populated with corresponding QA and Doc Tasks
(might be several of each) and the ags, set by the User Story
owner, that proper QA and documentation are done.
Testing and Documentation
Polarion Software

www.polarion.com
I hope you have gained some insights into how Scrum and Polarion ALM can work in con-
junction. In closing, let me suggest some possible next steps for you.
If you are new to Polarion ALM, I highly recommend our Test Drive Server where you can
explore Polarion ALM as much as you like without any time limits. For information and to
create your user account, visit www.polarion.com/products/alm/demo.php.
http://extensions.polarion.com here you can nd a constantly growing cadre of exten-
sions for Polarion, including examples of the Task Board I have referred to , workow
functions, integrations with third-party solutions, project templates, and more.
http://forums.polarion.com here you can ask questions and discuss with other cus-
tomers your approach to Polarion.
Nick Entin is VP for Research & Development at Polarion Software. Nick
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 Certied Scrum-
Master. You can read his prole at http://www.polarion.com/company/
people/index.php.
Conclusion
About the Author
Notes
Europe, Middle-East, Africa: Polarion Software GmbH
Lautlinger Weg 3 70567 Stuttgart, GERMANY
Tel +49 711 489 9969 - 0
Fax +49 711 489 9969 - 20
www.polarion.com - [email protected]
Americas & Asia-Pacic: Polarion Software, Inc.
406 Tideway Dr. Alameda, CA 94501, USA
Tel +1 877 572 4005 (Toll free)
Fax +1 510 814 9983
www.polarion.com - [email protected]
Did You Know?
Polarion Softwares integrated ALM
solutions manage requirements
engineering, team collaboration,
bug tracking, version control, CMMI
compliance, Agile process, and
more for many kinds of projects
with over 500,000 users world-
wide in broad range of industries.
Visit www.polarion.com for more
information.
PAGE 4
1
This is a string eld, because it should allow values like before version 3.2.1 or after nightly build Apr 12th 2008
2
Other work item types also have the Customer attribute, but it reects who has requested the feature or proposed an Improvement, so its role is less important
than in the Defect type.
PAGE 7
3
You might also congure special Hat Product Owner. I personally use my own table settings to expose the PBP column, so I can easily reshufe items.
PAGE 9
4
LivePlan reveals over/under- tasked people, potential bottlenecks, etc as soon as we plug in our tentative plan data.
PAGE 10
5
The Wiki Task Board is a free extension available on Polarion POP the Polarion extensions portal at http://extensions.polarion.com.
PAGE 11
6
Documentation may not happen in parallel with each iteration. Reality is that documenting all things together is not always possible. We use special a User Story
UNDONE: release X.Y.Z to link all the things to be addressed in a Stabilization Sprint before a corresponding release.
7
From a workow point of view, User Stories are marked as Implemented (programming is nished), Done (QAed, Documented), Veried-Done (when corre-
sponding stakeholder agrees that this functionality is really what was requested and expected). Those lacking documentation are still marked as Done, anticipat-
ing completion of documentation in a Stabilization Sprint.
PAGE 13
8
Otherwise unforeseen issues might cause implementation to vary from the original specication and lead to renement or even change of the specication. Of
course the Product Owner or corresponding stakeholders are the ones who ultimately decide any change of specication.