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
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!