{"id":886,"date":"2011-11-10T16:48:13","date_gmt":"2011-11-11T00:48:13","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/Polarion-Goes-Scrum-2011-Part-6\/ba-p\/380685"},"modified":"2026-03-26T05:32:11","modified_gmt":"2026-03-26T09:32:11","slug":"polarion-goes-scrum-2011-part-6","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/polarion-goes-scrum-2011-part-6\/","title":{"rendered":"Polarion Goes Scrum &#8211; 2011 (Part 6)"},"content":{"rendered":"<p><EM>By Nick Entin, VP R&amp;D, Polarion Software<\/EM><br \/>\n<H2>How Polarion Works during the Sprints<\/H2><br \/>\nIn the <a title=\"How Polarion uses Sprint Meetings\" href=\"http:\/\/blog.polarion.com\/archives\/1373\" target=\"_self\" rel=\"nofollow noopener noreferrer\">previous article<\/A> of this series we learned more about all the different meetings that are important part of Scrum.<\/p>\n<p>In this final post of this series, I\u2019ll describe how we manage the Sprint Progress in the Polarion development team.<br \/>\n<H3>Sprint: Development<\/H3><br \/>\nDuring 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.).<\/p>\n<p>The Polarion development process stipulates the following:<br \/>\n<UL><br \/>\n\t<LI>An integration build is run at least once per day (usually nightly).<\/LI><br \/>\n\t<LI>In case of build failure, the problems need to be fixed ASAP and a new build triggered.<\/LI><br \/>\n\t<LI>Failed unit tests should be treated with highest priority, and a build should be triggered again to confirm fixes of the unit tests.<\/LI><br \/>\n\t<LI>20% of each iteration\u2019s 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).<\/LI><br \/>\n\t<LI>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.<\/LI><br \/>\n<\/UL><br \/>\nEvery developer should know his\/her personal plan, which matches the team plan set during the planning meeting. Developers track tasks via\u2026<br \/>\nPersonal queries, like \u201cassigned to me in current Time Point\u201d<br \/>\n<UL><br \/>\n\t<LI>E-mail notifications of newly assigned work items<\/LI><br \/>\n\t<LI>The <EM>LivePlan<\/EM> chart and corresponding Wiki pages in our Polarion system<\/LI><br \/>\n<\/UL><br \/>\n<H3>How we burn down our Burn-down charts at Polarion<\/H3><br \/>\nThere are several possibilities in Polarion for projection of the Team\u2019s productivity and progress.<!--more--><br \/>\n<H4>1. LivePlan<\/H4><br \/>\nTraditionally there was a Gantt Chart, which allowed you to expose assignment of tasks to people, reflect dependencies and track progress. If you want to stay with traditional \u201cresource planning\u201d Polarion\u2019s <EM>LivePlan<\/EM> (see graphic on the left) is possibly the best tool for you.<\/p>\n<p><DIV style=\"background-color: #F9F9F9;border: 1px solid #CCCCCC;padding: 3px;font: 11px\/1.4em Arial, sans-serif;margin: 0.5em 0pt 0.5em 0.8em;width:300px;\"><A href=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-16-2011.png\" rel=\"nofollow noopener noreferrer\"><IMG class=\"size-medium wp-image-1683\" title=\"Polarion 2011 LivePlan\" src=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-16-2011-300x147.png\" alt=\"Screenshot: LivePlan\" width=\"300\" height=\"147\" \/><\/A><DIV style=\"text-align:center;\">The Polarion Live Plan<\/DIV> <\/DIV><\/p>\n<p>The LivePlan is configured to show only entities assigned to a Time Point (which most of the time means the current sprint). It shows only leaves of the work item work-break structure (i.e. it doesn\u2019t render  User Stories on the plan if a corresponding User Story has child items \u2013 improvements, tasks or defects).<\/p>\n<p>The LivePlan reflects holidays and other non-working days (configured in the global working calendar), vacation times and\/or days off (configured in developers\u2019 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.<\/p>\n<p>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.<br \/>\n<H4>2. Scrum Sprint Burn-down Chart<\/H4><br \/>\nWhile assignment of tasks to concrete person might be very important for a team leader or Scrum Master, for Product Owner or customer it&#8217;s more important how the whole team is doing. On the Planning Meeting the Team has committed to fulfill the plan, and doesn\u2019t matter if one person is late, rest of the team must help him to get the common goal achieved.<\/p>\n<p>In Agile processes you\u2019ll find several ways of visualization of the team\/sprint progress. We\u2019re using the so-called <EM>Burn-down chart<\/EM>. The chart allows you to see how efforts should ideally be distributed over the sprint time, and also shows actual progress.<\/p>\n<p><DIV style=\"background-color: #F9F9F9;border: 1px solid #CCCCCC;padding: 3px;font: 11px\/1.4em Arial, sans-serif;margin: 0.5em 0pt 0.5em 0.8em;width:300px;\"><A href=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-17-2011.png\" rel=\"nofollow noopener noreferrer\"><IMG class=\"size-medium wp-image-1685\" title=\"Example Burnd-own Chart\" src=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-17-2011-300x273.png\" alt=\"Screenshot: Polarion Burn-down Chart\" width=\"300\" height=\"273\" \/><\/A><DIV style=\"text-align:center;\">Example of a Burn-down Chart in Polarion<\/DIV> <\/DIV><\/p>\n<p>For example, the Burn-down chart above shows you that for the selected time frame User Stories of total 52 Story Points are supposed to be addressed and on the 3rd day of implementation, just about 7 are done.<\/p>\n<p>Note: There is nothing wrong with the chart so far, the chart supposes to show you progress when something is marked as \u201cdone\u201d only. This means that when sprint is started, you need at least some time to finish the first task. In an ideal situation the \u201cReal progress\u201d will stay above the \u201cIdeal Progress\u201d and go to 0 at end of the sprint. I\u2019d try to predict a question \u201cwhy shouldn&#8217;t &#8216;Real progress&#8217; go below the &#8216;Ideal\u201d&#8217;one?\u201d If you realize that your team is over-performing, it\u2019s a subject to reconsider during estimations for the future. In this case it may make sense to stop Sprint, add something to the plan and start the sprint again.<br \/>\n<H4>3. Road Map<\/H4><br \/>\nPolarion\u2019s Road Map view also gives a clear picture of the Work Items planned for the current sprint, this time in a tabular format.<\/p>\n<p><DIV style=\"background-color: #F9F9F9;border: 1px solid #CCCCCC;padding: 3px;font: 11px\/1.4em Arial, sans-serif;margin: 0.5em 0pt 0.5em 0.8em;width:300px;\"><A href=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-18-2011.png\" rel=\"nofollow noopener noreferrer\"><IMG class=\"size-medium wp-image-1688\" title=\"Project Road Map in Polarion\" src=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-18-2011-300x179.png\" alt=\"Screenshot: Project Roadmap in Polarion\" width=\"300\" height=\"179\" \/><\/A><DIV style=\"text-align:center;\">A Project Road Map in Polarion<\/DIV> <\/DIV><br \/>\n<H4>4. Scrum Product Burn-down Chart<\/H4><br \/>\nWorking in an Agile-pure development environment and planning just for short advance time \u2013 one sprint \u2013 is a comfortable area for development. You\u2019re committed to execute something, you carried out the promise and you delivered excellent results. Sounds like everybody should be happy. In reality, with&nbsp; Customer and PO also taking care that the \u201cbig-picture\u201d goal is achieved, it means that the progress of implementation is good enough to make sure that all the stories together will be done in time. This requires that you eventually get all the stories you want to implement in the release estimated, and that you start counting down the story points looking forward if the progress line prediction ends before estimated release date.<\/p>\n<p>An example of finished release:<\/p>\n<p><DIV style=\"background-color: #F9F9F9;border: 1px solid #CCCCCC;padding: 3px;font: 11px\/1.4em Arial, sans-serif;margin: 0.5em 0pt 0.5em 0.8em;width:300px;\"><A href=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-19-2011.png\" rel=\"nofollow noopener noreferrer\"><IMG class=\"size-medium wp-image-1691\" title=\"Finished release example\" src=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-19-2011-300x90.png\" alt=\"Screenshot: Finished release chart in Polarion\" width=\"300\" height=\"90\" \/><\/A><DIV style=\"text-align:center;\">Example for a completed release<\/DIV> <\/DIV><\/p>\n<p>Note that the graph doesn\u2019t necessarily go down all the time. This would happen only if you know in advance all the things to be done. If there will be further requirements added during implementation it might cause that the remaining estimations after the sprint end are actually bigger than at the beginning of the sprint. In the graph above you can see that shortly before release, there was a beta testing started and some feedback need to be addressed.<\/p>\n<p>Another example of the graph:<\/p>\n<p><DIV style=\"background-color: #F9F9F9;border: 1px solid #CCCCCC;padding: 3px;font: 11px\/1.4em Arial, sans-serif;margin: 0.5em 0pt 0.5em 0.8em;width:300px;\"><A href=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-20-2011.png\" rel=\"nofollow noopener noreferrer\"><IMG class=\"size-medium wp-image-1692\" title=\"Project graph - second example\" src=\"http:\/\/community.plm.automation.siemens.com\/legacyfs\/online\/siemensplm_blogs\/2011\/11\/6.1-Fig-20-2011-300x147.png\" alt=\"Screenshot: project graph, second example\" width=\"300\" height=\"147\" \/><\/A><DIV style=\"text-align:center;\">Example 2<\/DIV> <\/DIV><\/p>\n<p>Here you can see that at the beginning of the project there were a lot of new estimations and the graph went up at first. Next couple of sprints, new things were practically compensating implementation efforts. Now if the plan is fixed, remaining work could be addressed either in 1 sprint (the team has greater capacity for the current sprint compared to the previous one) or in 2 sprints if productivity will be exactly like in the last sprint (with less capacity).<br \/>\n<H3>Testing and Documentation<\/H3><br \/>\nAs implementation enters the \u201cImplemented\u201d state, it should be taken over to QA and Documentation.<\/p>\n<p>Of course there is automatic testing through unit tests and so on, but every feature should pass QA control to ensure:<br \/>\n<UL><br \/>\n\t<LI>Consistency of the implementation with other parts of the product.<\/LI><br \/>\n\t<LI>Acceptable levels of usability.<\/LI><br \/>\n\t<LI>Licensing and configuration for different product lines is implemented as specified.<\/LI><br \/>\n\t<LI>Common users acceptance \u2013 QA engineers are the first users, their feedback should be positive, of course.<\/LI><br \/>\n<\/UL><br \/>\nTypically QA and Documentation starts in parallel with development \u2013 based on a  specification document (normally a wiki page). Engineers create test cases, identify test steps and look for side effects of the functionality \u2013other 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.<\/p>\n<p>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.<\/p>\n<p>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.<br \/>\n<H3>Conclusion<\/H3><br \/>\nThanks for reading this series of posts on how we use the Scrum process at Polarion Software. I hope you have gained some useful information.<\/p>\n<p>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 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 \u2013 more cool features are in the works!<\/p>\n<p>In conclusion, let me offer you a couple of links that might prove helpful as you work with Polarion\u2019s ALM, Requirements Management, and Bug Tracking &amp; other solutions:<br \/>\n<A href=\"http:\/\/extensions.polarion.com\" rel=\"nofollow noopener noreferrer\">http:\/\/extensions.polarion.com<\/A>: 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.<\/p>\n<p><A href=\"http:\/\/forums.polarion.com\" rel=\"nofollow noopener noreferrer\">http:\/\/forums.polarion.com<\/A>: here you can ask questions and discuss with other customers your approach to Polarion.<\/p>\n<p><STRONG>What is your experience with using Scrum in your Development Processes? How do you work differently from the workflow I describe in the series?<\/STRONG><br \/>\nPlease share your comments and thoughts in the comments of this blog post. Thanks.<\/p>\n<p><HR \/><IMG src=\"http:\/\/www.polarion.com\/img\/team_Nikolay_Entin.jpg\" alt=\"Nick Entin\" hspace=\"4\" align=\"left\" \/><br \/>\n<EM>Editor&#8217;s Note: <\/EM><br \/>\nNick Entin is VP for Research &amp; 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 <a title=\"Scrum Alliance website\" href=\"http:\/\/www.scrumalliance.org\/\" target=\"_self\" rel=\"nofollow noopener noreferrer\">Scrum Alliance<\/A> and a <a title=\"Info on Scrum Alliance website\" href=\"http:\/\/www.scrumalliance.org\/pages\/certified_scrummaster\" target=\"_self\" rel=\"nofollow noopener noreferrer\">Certified ScrumMaster<\/A>. You can read his  profile at <a title=\"Polarion Software Management page\" href=\"http:\/\/www.polarion.com\/company\/people\/index.php\" target=\"_self\" rel=\"nofollow noopener noreferrer\">http:\/\/www.polarion.com\/company\/people\/index.php<\/A>.<\/p>\n<p><HR \/><\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Nick Entin, VP R&amp;D, Polarion Software<br \/>\n How Polarion Works during the Sprints<br \/>\nIn the previous article of this series we learned more about all the different meetings that are important part of&#8230;<\/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-886","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/886","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=886"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/886\/revisions"}],"predecessor-version":[{"id":887,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/886\/revisions\/887"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/media?parent=886"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/categories?post=886"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/tags?post=886"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/industry?post=886"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/product?post=886"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/coauthors?post=886"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}