Polarion goes Scrum (Part 4)

Product Backlog

by Nick Entin, VP Research & Development, Certified ScrumMaster

Typically Product Owner would write Excel or Word document with his items and then simply reshuffles them according priorities. Of course any ticketing system would allow management of such artifacts in good way, so does Polarion.

Composing User Stories

We use 3 ways of composing User Stories:

• Through Polarion Web UI (“Create WorkItem”)


• Through Email (send Email to Polarion Mailet)


• Through LiveDocs

In either way created WorkItems appear in Tracker and it’s relatively easy for all stakeholders to find them using our QueryBuilder (e.g. for our configuration a query might be “type:userstory AND backlog:usability“), or such queries might be included into a Wiki page:

Prioritizing of UserStories

This is the point where our process differs from typical. As mentioned above, we have several relatively independent stakeholders, who are committed to common goal, but somehow pursuit own target (known situation, isn’t it? 😉) I.e. we 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 corresponding Backlog Owner. Also Backlog owner defines 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 Figure 8 above, which collects those backlogs and visualizes the top items:

Extracting from specific Backlogs to Product Backlog

Next step should be to collect all the required items for the Product Backlog – it’s relatively easy to create Wiki, which collects all the “top” items from corresponding backlogs.

Next step will be to give 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 WorkItems table. You may configure special Hat for Product Owner, or 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. I.e. 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 WorkItems, we actively use Autoassignment feature, which allows immediately select a Senior Developer, who potentially will be leading the implementation, he gets Email notification and see this new item assigned to him. This way we encourage early review of posted user stories, already filtered input for the planning meetings, etc.

For simplifying prioritization the “weight” or “initial estimate” of a UserStory is important and automatic assignment helps to get initial review and communication even before the Planning Meeting.

Also we’ve configured UserStories to aggregate Remaining Estimates from the children items.
It means that by brainstorming and agreement on the Planning Meeting we identify Initial Estimate of a UserStory. However later, when it is decomposed to Improvement, Tasks and Defects, one can recognize some variations, i.e. that particular work actually takes less time, or some additional task was not counted and discovered after implementation begin.
This data is extremely helpful for re-planning of the UserStory to next Sprint, if it wasn’t finished properly.

Note: we pay special attention to UserStories, which were committed to a Sprint, but was not completed properly. It’s very naturally to let it go to the next Sprint because “it’s just took a little longer than was planned, therefore it isn’t done yet”. 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 UserStories to end of 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 UserStory remains unfinished this and may be next Sprint.

This is very popular question on our Planning Meeting: “If this UserStory was not addressed on last Sprint, how could we ensure that our new commitment to this UserStory will be really realized?”

Next time…

In the next post I’ll talk about Sprints and how we handle them in the Polarion development team.

---

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.

---