Polarion goes Scrum (part 6)

by Nick Entin

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 TimePoint”


• E-mail notifications of newly assigned work items


• The LivePlan chart and corresponding Wiki pages in our Polarion system

Burn-down Charts

In Polarion we use dynamic calculation of the project plan – the so-called LivePlan view:

The LivePlan is configured to show only entities assigned to a TimePoint (which most of the time means the current sprint). It shows only leaves of the work item work-break structure (i.e. it doesn’t render User Stories on the plan if a corresponding User Story has child items – improvements, tasks or defects).

The LivePlan reflects holidays and other non-working days (configured in the global working calendar), vacation times and/or days off (configured in developers’ personal working calendars), and items from different projects. This way it presents very readable and clear information whether or not the Sprint goals are still achievable, if performance of the team is sufficient to complete the goals in the sprint time frame, if there are delays, and if yes, who is overloaded and which tasks are at risk.

The plan is ordered by priorities and severities in the way developers have agreed upon in the Planning Meeting (Part II) . Correspondingly, at the end of the plan should be less important items.

In addition to the LivePlan we have Wiki pages that highlight the progress of the team and remaining time:

Polarion’s Road Map view also gives a clear picture of the work items in tabular form:

Testing and Documentation

As implementation enters the “Implemented” state, it should be taken over to QA and Documentation.

Of course there is automatic testing through unit tests and so on, but every feature should pass QA control to ensure:

• Consistency of the implementation with other parts of the product


• Acceptable levels of usability


• Licensing and configuration for different product lines is implemented as specified


• Common users acceptance – QA engineers are the first users, their feedback should be positive, of course

Typically QA and Documentation starts in parallel with development – based on a specification document (normally a wiki page). Engineers create test cases, identify test steps and look for side effects of the functionality –other test cases may need to be updated to reflect availability of the new feature/functionality. Doc writers start to think of structure of the documentation, selection of keywords and thinking of cross linking of documentation topics.

In our organization, final definition of the test cases and documentation typically happens at the point, where implementation is really considered done, and first round of review (also by QA) is passed. Otherwise it might happen that unforeseen issues cause implementation to vary from the original specification and it actually leads to refinement or even change of the specification. Of course the product owner or corresponding stakeholders are the ones who ultimately decide any change of specification.

The User Story is populated with corresponding QA and Doc Tasks (might be several of each) and the flags, set by the User Story owner, that proper QA and documentation are done.

Conclusion

Thanks for reading this series of posts on how we use the Scrum process at Polarion Software. I hope you have gained some useful information.

Polarion ALM is bundled with some project templates that can help you instantiate the Scrum-framework in corresponding projects of your own. Polarion ALM is quite rapidly growing software and some of the topics in this post series, including screenshots, might already be outdated by the time you read this. But the changes are always happening for the benefit of our users! Stay tuned – more cool features are in the works!

In conclusion, let me offer you a couple of links that might prove helpful as you work with Polarion’s ALM, Requirements Management, and Bug Tracking & Team Collaboration solutions:

• http://extensions.polarion.com – here you can find a constantly growing cadre of extensions for Polarion, including examples of the Task Board I have referred to , workflow functions, integrations with third-party solutions, project templates, and more.


• UPDATE: Now there’s a Polarion-certified Project Template Extension that makes it easy to run Scrum projects with Polarion ALM


• http://forums.polarion.com – here you can ask questions and discuss with other customers your approach to Polarion.

---

Editor’s Note:
This concludes the article series Polarion Goes Scrum by Nick Entin, 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 Certified ScrumMaster. You can read his profile at http://www.polarion.com/company/people/index.php.