Polarion goes Scrum (part 2)
Iterative incremental Development
by Nick Entin, VP Research & Development, Certified ScrumMaster
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.
Major Benefits of Polarion Scrum Development
- Shorten time to release to the market
- Transparency to management/customers
- Faster reaction to market needs; confidence of customers in Polarion’s development
- Simplifies synchronization of distributed teams
- Faster feedback from the field
- Easier releasing – smaller stabilization sprint, less things to test
- Flexibility in prioritization, risk reduction
Polarion’s Iterative development calls for very short iterations – 2 weeks, with meetings at the beginning and the end of the iteration: an Iteration Planning Meeting and an Iteration Assessment meeting.
Strategically each sprint is focused to equally cover 3 major areas of the application:
- New Feature implementation
- Performance and Usability
- Stability
Development capacities are divided to cover these areas during the planning meeting.
As mentioned, the Iteration length is set to 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 10 team members.
In our development, it’s hard to start with single Product Backlog, as there are too many stakeholders, who want to prioritize 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 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.
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- which will be the subject of Part 3 of this series. Stay tuned!
UPDATE: Now there’s a Polarion-certified Project Template Extension that makes it easy to run Scrum projects with Polarion ALM
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.
