Polarion Goes Scrum – 2011 (Part 6)
By Nick Entin, VP R&D, Polarion Software
How Polarion Works during the Sprints
In the previous article of this series we learned more about all the different meetings that are important part of Scrum.
In this final post of this series, I’ll describe how we manage the Sprint Progress in the Polarion development team.
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 Time Point”
- E-mail notifications of newly assigned work items
- The LivePlan chart and corresponding Wiki pages in our Polarion system
How we burn down our Burn-down charts at Polarion
There are several possibilities in Polarion for projection of the Team’s productivity and progress.
1. LivePlan
Traditionally 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 “resource planning” Polarion’s LivePlan (see graphic on the left) is possibly the best tool for you.
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’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.
2. Scrum Sprint Burn-down Chart
While assignment of tasks to concrete person might be very important for a team leader or Scrum Master, for Product Owner or customer it’s more important how the whole team is doing. On the Planning Meeting the Team has committed to fulfill the plan, and doesn’t matter if one person is late, rest of the team must help him to get the common goal achieved.
In Agile processes you’ll find several ways of visualization of the team/sprint progress. We’re using the so-called Burn-down chart. The chart allows you to see how efforts should ideally be distributed over the sprint time, and also shows actual progress.
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.
Note: There is nothing wrong with the chart so far, the chart supposes to show you progress when something is marked as “done” only. This means that when sprint is started, you need at least some time to finish the first task. In an ideal situation the “Real progress” will stay above the “Ideal Progress” and go to 0 at end of the sprint. I’d try to predict a question “why shouldn’t ‘Real progress’ go below the ‘Ideal”’one?” If you realize that your team is over-performing, it’s 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.
3. Road Map
Polarion’s Road Map view also gives a clear picture of the Work Items planned for the current sprint, this time in a tabular format.
4. Scrum Product Burn-down Chart
Working in an Agile-pure development environment and planning just for short advance time – one sprint – is a comfortable area for development. You’re committed to execute something, you carried out the promise and you delivered excellent results. Sounds like everybody should be happy. In reality, with Customer and PO also taking care that the “big-picture” 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.
An example of finished release:
Note that the graph doesn’t 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.
Another example of the graph:
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).
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 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 & other 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.
http://forums.polarion.com: here you can ask questions and discuss with other customers your approach to Polarion.
What is your experience with using Scrum in your Development Processes? How do you work differently from the workflow I describe in the series?
Please share your comments and thoughts in the comments of this blog post. Thanks.
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.
