\nby Nick Entin, VP Research & Development, Certified ScrumMaster<\/EM><\/p>\n
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.<\/p>\n
![\"Figure](\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2009\/05\/figure1.png\")
\n
Major Benefits of Polarion Scrum Development<\/H2>
\n
\n\t- Shorten time to release to the market<\/LI>
\n\t - Transparency to management\/customers<\/LI>
\n\t - Faster reaction to market needs; confidence of customers in Polarion\u2019s development<\/LI>
\n\t - Simplifies synchronization of distributed teams<\/LI>
\n\t - Faster feedback from the field<\/LI>
\n\t - Easier releasing \u2013 smaller stabilization sprint, less things to test<\/LI>
\n\t - Flexibility in prioritization, risk reduction<\/LI>
\n<\/UL>
\nPolarion\u2019s Iterative development calls for very short iterations \u2013 2 weeks, with meetings at the beginning and the end of the iteration: an Iteration Planning Meeting and an Iteration Assessment meeting.<\/p>\n![\"Figure](\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2009\/05\/figure2.png\")
Figure 2<\/DIV> <\/DIV><\/p>\nStrategically each sprint is focused to equally cover 3 major areas of the application:
\n
\n\t- New Feature implementation<\/LI>
\n\t - Performance and Usability<\/LI>
\n\t - Stability<\/LI>
\n<\/UL>
\nDevelopment capacities are divided to cover these areas during the planning meeting.<\/p>\nAs mentioned, the Iteration length is set to 2 weeks, which we have thus far found optimal for a team the size of Polarion\u2019s R&D department \u2013 i.e. several teams with 3 to 10 team members.<\/p>\n
In our development, it\u2019s 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 \u2013 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\u2019t specify exactly what is expected, just a general direction, like \u201cwe need XXX Integration, because our competitors also have it\u201d.<\/p>\n
So in our environment we have to face the necessity of collaboration with many people from different locations and positions to identify:
\n
\n\t- Product Backlog items \u2013 these should be described in way that at least the idea behind each one is clear. Therefore we\u2019re using User Stories, because it\u2019s always easier to describe \u201cI like to have\u201d, than to write a technical specification and get complaints that it\u2019s not absolutely clear.<\/LI>
\n\t - Business value for Backlog items \u2013 as described above it\u2019s not a single-person decision. Communication and proper means of storing information is required, and consistency about agreements is especially important.<\/LI>
\n<\/UL>
\nThe following picture illustrates process of composing the Product Backlog:<\/p>\n![\"Figure](\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2009\/05\/figure3.png\")
Figure 3<\/DIV> <\/DIV><\/p>\nIn our case backlogs are mostly populated from the following sources:
\n
\n\t- Feature Backlog<\/STRONG> 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.<\/LI>
\n\t- Usability Backlog<\/STRONG> is populated by the Product Management, PSO\/sales and Development Team<\/LI>
\n\t- Process Backlog<\/STRONG> reflects requests concerned with how to improve productivity of internal development and provide more transparency to the management \u2013 populated by PM and Development Team.<\/LI>
\n\t- Performance Backlog<\/STRONG> is populated by the Development Team based on continuous profiling of the product and reviews of possible architectural refactoring of the product.<\/LI>
\n\t- Integrations Backlog<\/STRONG> 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.<\/LI>
\n\t- QA Backlog<\/STRONG> is focused on testing activities, identification of defects that \u201cmust be fixed in next release\u201d, etc.<\/LI>
\n<\/UL>
\nDuring 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.<\/p>\nThe planning entity for the sprint is a UserStory. Each UserStory has customer (the person who formulated the requirement) and an owner \u2013 typically a Senior Developer, who then follows the User Story through the full ALC.<\/p>\n
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.<\/p>\n
Now we\u2019re moving to most sensitive and, of course, most interesting part: how Polarion ALM<\/A> helps and supports us in applying Scrum practices- which will be the subject of Part 3 of this series. Stay tuned!<\/p>\n
\nUPDATE:<\/STRONG> Now there’s a Polarion-certified Project Template Extension<\/A> that makes it easy to run Scrum projects with Polarion ALM<\/P>
\n<\/DIV><\/p>\n
![\"Nick](\"http:\/\/www.polarion.com\/img\/team_Nikolay_Entin.jpg\")
\nEditor’s Note: <\/EM>
\nNick 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<\/A> and a Certified ScrumMaster<\/A>. You can read his profile at http:\/\/www.polarion.com\/company\/people\/index.php<\/A>.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"Iterative incremental Development
\nby Nick Entin, VP Research & Development, Certified ScrumMaster<\/p>\n
Traditional development supposes long-term planning in advance and performing all relevant acti…<\/p>\n","protected":false},"author":68980,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[],"industry":[],"product":[],"coauthors":[],"class_list":["post-1316","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1316","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/users\/68980"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/comments?post=1316"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1316\/revisions"}],"predecessor-version":[{"id":1317,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1316\/revisions\/1317"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/media?parent=1316"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/categories?post=1316"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/tags?post=1316"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/industry?post=1316"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/product?post=1316"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/coauthors?post=1316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\t
\n\t
\n\t
\n\t
\n\t
\n\t
\n\t
\n<\/UL>
\nPolarion\u2019s Iterative development calls for very short iterations \u2013 2 weeks, with meetings at the beginning and the end of the iteration: an Iteration Planning Meeting and an Iteration Assessment meeting.<\/p>\n
Strategically each sprint is focused to equally cover 3 major areas of the application:
\n
- New Feature implementation<\/LI>
\n\t - Performance and Usability<\/LI>
\n\t - Stability<\/LI>
\n<\/UL>
\nDevelopment capacities are divided to cover these areas during the planning meeting.<\/p>\nAs mentioned, the Iteration length is set to 2 weeks, which we have thus far found optimal for a team the size of Polarion\u2019s R&D department \u2013 i.e. several teams with 3 to 10 team members.<\/p>\n
In our development, it\u2019s 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 \u2013 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\u2019t specify exactly what is expected, just a general direction, like \u201cwe need XXX Integration, because our competitors also have it\u201d.<\/p>\n
So in our environment we have to face the necessity of collaboration with many people from different locations and positions to identify:
\n- Product Backlog items \u2013 these should be described in way that at least the idea behind each one is clear. Therefore we\u2019re using User Stories, because it\u2019s always easier to describe \u201cI like to have\u201d, than to write a technical specification and get complaints that it\u2019s not absolutely clear.<\/LI>
\n\t - Business value for Backlog items \u2013 as described above it\u2019s not a single-person decision. Communication and proper means of storing information is required, and consistency about agreements is especially important.<\/LI>
\n<\/UL>
\nThe following picture illustrates process of composing the Product Backlog:<\/p>\nFigure 3<\/DIV> <\/DIV><\/p>\nIn our case backlogs are mostly populated from the following sources:
\n- Feature Backlog<\/STRONG> 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.<\/LI>
\n\t- Usability Backlog<\/STRONG> is populated by the Product Management, PSO\/sales and Development Team<\/LI>
\n\t- Process Backlog<\/STRONG> reflects requests concerned with how to improve productivity of internal development and provide more transparency to the management \u2013 populated by PM and Development Team.<\/LI>
\n\t- Performance Backlog<\/STRONG> is populated by the Development Team based on continuous profiling of the product and reviews of possible architectural refactoring of the product.<\/LI>
\n\t- Integrations Backlog<\/STRONG> 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.<\/LI>
\n\t- QA Backlog<\/STRONG> is focused on testing activities, identification of defects that \u201cmust be fixed in next release\u201d, etc.<\/LI>
\n<\/UL>
\nDuring 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.<\/p>\nThe planning entity for the sprint is a UserStory. Each UserStory has customer (the person who formulated the requirement) and an owner \u2013 typically a Senior Developer, who then follows the User Story through the full ALC.<\/p>\n
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.<\/p>\n
Now we\u2019re moving to most sensitive and, of course, most interesting part: how Polarion ALM<\/A> helps and supports us in applying Scrum practices- which will be the subject of Part 3 of this series. Stay tuned!<\/p>\n
\nUPDATE:<\/STRONG> Now there’s a Polarion-certified Project Template Extension<\/A> that makes it easy to run Scrum projects with Polarion ALM<\/P>
\n<\/DIV><\/p>\n
\nEditor’s Note: <\/EM>
\nNick 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<\/A> and a Certified ScrumMaster<\/A>. You can read his profile at http:\/\/www.polarion.com\/company\/people\/index.php<\/A>.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"Iterative incremental Development
\nby Nick Entin, VP Research & Development, Certified ScrumMaster<\/p>\nTraditional development supposes long-term planning in advance and performing all relevant acti…<\/p>\n","protected":false},"author":68980,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[],"industry":[],"product":[],"coauthors":[],"class_list":["post-1316","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1316","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/users\/68980"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/comments?post=1316"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1316\/revisions"}],"predecessor-version":[{"id":1317,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1316\/revisions\/1317"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/media?parent=1316"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/categories?post=1316"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/tags?post=1316"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/industry?post=1316"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/product?post=1316"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/coauthors?post=1316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Usability Backlog<\/STRONG> is populated by the Product Management, PSO\/sales and Development Team<\/LI>
\n\t - Feature Backlog<\/STRONG> 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.<\/LI>
\n\t - Product Backlog items \u2013 these should be described in way that at least the idea behind each one is clear. Therefore we\u2019re using User Stories, because it\u2019s always easier to describe \u201cI like to have\u201d, than to write a technical specification and get complaints that it\u2019s not absolutely clear.<\/LI>
\n\t