Polarion Software Weblog

By Nick Entin, VP R&D, Polarion Software

How Polarion Works during the Sprints

In the previous article of this series we learned more about all the different meetings that are important part of Scrum.

In this final post of this series, I’ll describe how we manage the Sprint Progress in the Polarion development team.

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.).

The Polarion development process stipulates the following:

• An integration build is run at least once per day (usually nightly).
• In case of build failure, the problems need to be fixed ASAP and a new build triggered.
• Failed unit tests should be treated with highest priority, and a build should be triggered again to confirm fixes of the unit tests.
• 20% of each iteration’s development time is reserved as buffer for unpredicted activities (e.g. a critical defect or failed unit tests, or an urgent support request from a customer).
• If for some reason the buffer is exceeded, or senior management requires execution of some unplanned items, the iteration should be cancelled and a new plan created.

Every developer should know his/her personal plan, which matches the team plan set during the planning meeting. Developers track tasks via…
Personal queries, like “assigned to me in current Time Point”

• E-mail notifications of newly assigned work items
• The LivePlan chart and corresponding Wiki pages in our Polarion system

How we burn down our Burn-down charts at Polarion

There are several possibilities in Polarion for projection of the Team’s productivity and progress. (more…)

By Nick Entin, VP R&D, Polarion Software

How Polarion Uses Sprint Meetings

Meetings are possibly the most important assets of Scrum. As described in previous articles, Scrum allows us to identify problems and helps us find ways to resolve them. Meetings are the when the team commits to the Product Owner on the amount of work (features) they will address over the sprint. They discuss the progress in Daily Scrums and, finally, assess results at the last meeting.

In this and the next and final post of this series, I’ll describe how we manage those meetings with the Polarion development team.

Daily Scrums

Scrums might be the most complicated part of Scrum – this requires a change of minds. Too many of us interpret meetings as means of getting tasks and reporting back, but Scrum in general, and Daily Scrums particular, are about helping the team to understand current situation correctly and to be able to adjust if necessary to get the targets done. Daily Scrums allow team members to synchronize, understand as one entity whether Sprint goals are still feasible, if we’re really “right on time” and if not, take decisions about what to change. Nobody should be collecting reports on the meeting, and the Scrum Master should set one simple question and make sure that everybody knows the  answer to it: “Are we sure we’ll meet our Sprint goals? Please show/explain how we do that!”

We use the Sprint Board in Polarion ALM’s integrated Wiki to track progress of our Sprint execution, a really nice and useful Velocity Macro on our active Wiki pages:

We have several teams in our development department working on the same project, and we can easily switch from one team’s Sprint Board to another or see an aggregate overview:

Look useful? The functionality I’ve shown you in the screenshots is provided by the Scrum Project project template, included in all distributions of Polarion ALM 2011.

The Assessment Meeting

Every iteration ends with an Iteration Assessment Meeting, where every developer presents his work, either in the form of a document if the task was to “specify” or “analyze” or “profile”, or as a demo of the work as it has been implemented in the product.

By the Assessment Meeting, the User Story should be already tested by QA and documented (or prepared for documentation). Experience shows that documenting everything implemented in a sprint during the same sprint is not always feasible. For example, if documentation should reflect a feature that is implemented over two or more sprints, or a feature is finished late in the sprint. In the assessment meeting, Doc writers have chance to see how functionality really works and understand the scope of the documentation work. So we have set constraint that all the features implemented in Sprint X must be documented in Sprint X+1.

From a workflow point of view, User Stories are marked as “Implemented” (programming is finished), “Done” (QAed, Documented), “Verified-Done” (when corresponding stakeholder agrees that this functionality is really what he requested and expected).
For the Assessment Meetings we check only those marked as “Done”.

The Retrospective (Lessons Learned)

This is the end-part of the Assessment Meeting. Ideally, it is a time to discuss how we could optimize the process to implement yet more Items over a sprint, but more typically we’re find ourselves trying to assess and identify things that were less than perfect in our process and/or the implementation of some feature during the sprint.

We also try to identify additional synchronization risks, communication problems, involve additional people to show them some dependency, which was not fulfilled, and other subjects we feel we need to discuss.

NEXT…

In the next and final article of the series, I’ll take you inside our daily development and share how we work during each Sprint.

By Nick Entin, VP R&D, Polarion Software

Polarion’s Product Backlog: composition and priorities

In the third article in this series, I shared some of the Polarion R&D team’s not-so-secret secrets for configuring Polarion to support the way we work with Scrum.

In this fourth article I will discuss the various backlogs we have in the Polarion R&D team, and how we populate and prioritize them.

The “main” backlog is the Product Backlog. Ideally, the Product Owner would write an Excel or Word document with his items for this backlog, and then simply reshuffle them according priorities. Of course any ticketing system would allow management of such artifacts in a good way, and Polarion is no exception. But as you may surmise, there’s more to it than that, at least for us.

Before getting into the details of Polarion’s Product Backlog, let’s look at how we create and prioritize the User Stories that comprise it.

Composing Epics and User Stories

You may notice that we’re using customized form layout for User Stories, making the most important attributes visible directly in the top-area of the Work Item.

Newly created Work  Items appear in Tracker and it’s relatively easy for all stakeholders to find them using our Query Builder (e.g. for our configuration a query might be “type:userstory AND backlog:usability“), or such queries might be included into a Wiki page using the {workitems} macro:

Prioritizing User Stories

This is the point where our process differs from typical Scrum. As mentioned above, we have several relatively independent stakeholders, who are committed to common goal, but somehow pursue their own target (not an unknown situation, is it? ) For example, our Support Lead might want to address integration with third-party software, because several customers are trying to implement it themselves and flooding support with relevant requests. Of course this guy knows that there are other important features or problems, but he doesn’t want to compare if his idea is more important or less.

In our case, each backlog is prioritized separately by the corresponding Backlog Owner. Also, the Backlog owner defines the threshold of his items – those items must appear in the Product Backlog and, ideally, should be discussed by the team.

We created a Wiki page like the one shown in the figure above, which collects those backlogs and visualizes the top items:

Extracting from specific Backlogs to Product Backlog

The next step should be to collect all the required items for the Product Backlog – it’s relatively easy to create a query which collects all the “top” items from corresponding backlogs and displays the results in a Wiki page:

Polarion R&D team's product backlog as a wiki page in Polarion ALM

The next step will be for the Product Owner to prioritize the list. We’ve defined new custom field “Product Backlog Priority” (PBP) with type Integer, where PO may sort the items accordingly.

Nice thing in Polarion – you may click “More” in the Wiki’s table to open the Work Items table. You may configure special View for the Product Owner. I use personal table settings to expose PBP column, so I can easily reshuffle items.

The PBP attribute also helps to track down if there were some changes in particular backlog, but not yet reflected in the Common one — a query, which lists all the “important” user stories, which don’t have the PBP initialized:

Items from other backlogs not yet in the Product Backlog

Additional tips from our development process

During creation of Work Items, we actively use Polarion’s Auto-assignment feature, which immediately assigns a Senior Developer, who potentially will be leading the implementation. He gets email notification and sees this new item assigned to him. This way we encourage early review of posted user stories, already-filtered 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 even before the Planning Meeting.

Also we’ve configured Epics to aggregate Remaining Estimates from the child User Stories. This data allows us to calculate remaining efforts for the release and keep track of whether a big feature is implemented fully or just partially.

Note: we pay special attention to any User Story(ies) committed to a Sprint, but not completed properly. It’s very natural to let these go to the next Sprint because “it’s just took a little longer than was planned, therefore it isn’t done yet”. The intuitive expectation is that as soon it’s moved to next Sprint, it will be done in the first day. No! Practice shows that developers quite often leave unfinished User Stories to end of the iteration because it’s easy to complete and they know exactly what to do. This, however, doesn’t match to reality – they get late with other tasks, and this Use rStory remains unfinished in yet another Sprint.

A very popular question on our Planning Meeting is: “If this User Story was not addressed during this Sprint, how can we ensure that our new commitment to this User Story will be actually realized?”

In the next article, I’ll give you a sneak peek inside our Sprint meetings!

By Nick Entin, VP R&D, Polarion Software

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

• 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 from  two 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 to  a 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.

By Nick Entin, VP R&D, Polarion Software
In the first article in this series, I talked about the reasons that led Polarion’s R&D team to adopt Scrum to manage the development of Polarion software solutions. In this article, I’ll discuss the benefits our team derives from…

Incremental Iterative Development

Traditional development supposes long-term planning in advance and performing all relevant activities before product hits the market. Scrum recommends a highly-adaptive way of development with short iterations producing fully tangible results.

Composition of Polarion's 2-week Sprint

All the Application Lifecycle (ALC) activities may be done in parallel because the specification of one feature, which could be implemented in the next iteration, can be done in parallel with implementation of another feature already specified in a previous iteration.
Now that we understand the why’s and wherefores behind Polarion’s adoption of Scrum, the next post in this series will examine how we integrate the various roles and responsibilities, factor in risk, and plan Sprints.

2.1 Roles, Responsibilities and Risks

When implementing a process, you have to decide who fills what roles and which responsibilities are assigned. In real life any organization has hierarchy of management, “important” customers and one or more teams who are to implement defined requirements and deliver products or solutions. Naturally there might be conflicts, which should be clearly identified and resolved.

One such conflict is directives from management: “you have to implement this task in 3 weeks”, for example.

Why do I call it as a conflict? Because it’s actually delegation of a risk to somebody, who doesn’t care too much. My favorite exercise from Ken Schwaber’s Scrum Training – Risk.

Suppose you’ve got a genius idea and you want to implement it. You know that implementation efforts might cost $1million, but you’re sure that this idea is so great that you can return this investment in 1 year. The problem is that you possibly don’t have this $1million so you go and collect the money from all possible sources. Good, availability of the money is ensured, now you’re looking for a team which can do the real work. You spend your time and define requirements – you’re good and you write a50-page Word document, and you feel very confident that the project is feasible.

Now you approach a team and ask them: “Hey guys, I want you to implement this project, here are the requirements, can you do it in 6 months?”. If the team has enough engineers and experienced in particular area, most likely you’ll get answer “Yes, we can. It will cost you $XXX”.

Now we return to my question why I call it a conflict. If the team will implement the project in specified time/money – you’re lucky, there is nothing to discuss. But what happen, if they fail. Who faces what risks here?

The Engineering company you hired, in worst case, will lose some reputation. But you may lose everything – you need to return $1 million and there is no product (or not in time), to give you the chance. Possibly your entire life is broken from this point.

In many situations, directives from management “implement X in time Y” look very similar. Developers are not risking much if they fail with the goal, but the company may face much more dramatic consequences.

Scrum is a framework which gives you a chance to base your decisions or promises on already-collected experience, rather than to place the bet on a one-shot statement.

For example,  your development team may tell you “we’re absolutely sure your Requirements document is very detailed and well specifies what we need to do in 6 months, so let us start, we’ll see each other in 6 months for project delivery”. Could that be real? When you think about this question, do you really think are you personally able to specify every requirement for a project lasting several months, and be confident that you haven’t forgotten anything and will not want or need to change/clarify things All of this requires clarification of responsibilities and commitment.

Scrum defines several core Roles:

Sprint Planning

In Polarion strategically each sprint is focused to equally cover 3 major areas of the application:

• New Feature implementation
• Performance and Usability
• Stability/Quality

Product Owner is responsible to find compromise on how to prepare Product Backlog to cover these areas during the upcoming sprint.

As mentioned, our Iteration length is 2 weeks, which we have thus far found optimal for a team the size of Polarion’s R&D department – i.e. several teams with 3 to 6 team members.

In our development, it’s hard to start with a single Product Backlog, as there are too many stakeholders who want to prioritize their own things first. E.g. there is the Professional Services team, who help customers onsite and who have their own usability wish list (BTW, experience shows that usability requests in Europe are very often different from those in the US – so be careful, when prioritizing ). There is also the Support team, which calls attention to common problems, and of course there is Senior Management, who want to see some big features, but they can’t specify exactly what is expected, just a general direction, like “we need XXX Integration, because our competitors also have it”.

So in our environment we have to face the necessity of collaboration with many people from different locations and positions to identify:

• Product Backlog items – these should be described in way that at least the idea behind each one is clear. Therefore we’re using Epics and User Stories, because it’s always easier to describe “I like to have”, than to write a technical specification and get complaints that it’s not absolutely clear.
• Business value for Backlog items – as described above it’s not a single-person decision. Communication and proper means of storing information is required, and consistency about agreements is especially important.

To make it more practical, we did following: the Product Backlog is composed from several other Backlogs – each Backlog has its owner stakeholder. However, anybody in the company is allowed to post new items there. The backlogs contain broad descriptions of all required features and wish-list items. The  Product Owner’s responsibility is to populate the Product Backlog from those specific backlogs. During the Sprint Planning meeting, the Product Owner discusses the items with the development team. When necessary, Backlog Owners are invited in.

The following picture illustrates process of composing the Product Backlog.

In our case backlogs are mostly populated from the following sources:

• Feature Backlog is populated by Product Management, who collect requests from the Customer Demand list (where PM identifies priority from the customer perspective, business opportunities, and check if a request is customer-specific or popular among several customers),  from the Professional Services Organization (PSO), from the Development Team, from Community users and so on.

• Usability Backlog is populated by the Product Management, PSO/sales and Development Team
• Process Backlog reflects requests concerned with how to improve productivity of internal development and provide more transparency to the management – populated by PM and Development Team.
• Performance Backlog is populated by the Development Team based on continuous profiling of the product and reviews of possible architectural refactoring of the product.
• Integrations Backlog is populated by the PSO and Development Team based on input from the customers, potential clients and opportunities for better exposure to or acceptance of Polarion ALM by the customers.
• QA Backlog is focused on testing activities, identification of defects that “must be fixed in next release”, etc.

During the Planning Meeting dependencies between teams are also identified to allow as much parallel work by the teams as possible, keeping the same focus for the iteration.

The planning entity for the sprint is a UserStory. Each UserStory has customer (the person who formulated the requirement) and an owner – typically a Senior Developer, who then follows the User Story through the full ALC.

The second part of the planning meeting is dedicated to splitting the UserStories into concrete Tasks and Improvements. It also helps in the initial steps of creating technical specifications out of the non-technical language descriptions, in the coordination of QA activities, and the provision input to the Documentation team.

Now we’re moving to most sensitive and, of course, most interesting part: how Polarion ALM helps and supports us in applying Scrum practices… the subject of the next article in this series.