Polarion Goes Scrum – 2011 (Part 4)
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
- Through the Polarion Web UI – “Create Work Item” or “Create Document”
- Using Email (send Email to Polarion Mailet)
- Or via importing a Word document to Polarion.
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 WorkItems 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:
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:
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!
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.
