Polarion Goes Scrum – 2011 (Part 5)
By Nick Entin, VP R&D, Polarion Software
How Polarion Uses Sprint Meetings
Meetings are possibly the most important assets of Scrum. As described in previous articles, Scrum allows us to identify problems and helps us find ways to resolve them. Meetings are the when the team commits to the Product Owner on the amount of work (features) they will address over the sprint. They discuss the progress in Daily Scrums and, finally, assess results at the last meeting.
In this and the next and final post of this series, I’ll describe how we manage those meetings with the Polarion development team.
The Estimation Meeting
Before any product development may be started and accurate planning executed, we need to ensure that developers understand the customer’s demand, and that they have the same estimations for the implementation efforts. Therefore, every week we dedicate a time slot in which we go over not-yet-discussed User Stories and Epics. Typically, every developer needs to analyze 1-2 items and present his thoughts to the rest of the team. Then the team has a short (or long!) discussion about the subject, the Customer and PO confirm the expectation, and then Planning Poker is used to estimate stories in Story Points.
During the Estimation meeting we identify demand to convert some User Stories to Epics and just pick up some piece of the Epic for estimation.
The Planning Meeting
The goal of the Planning Meeting is to reconfirm that the team fully understands the Product Backlog items, to commit the team to implementing agreed-on items in upcoming sprint, and to ensure proper distribution of work among team members.
Typically the meeting is split to two parts. The first part involves the Product Owner, and possibly other stakeholders, if required to clarify backlog items, confirmation of common understanding of things to be done and commit the team to some items. The second part is a rather internal meeting, where the team decides who will implement what. We check decomposition of User Stories to child Tasks, Improvements, and Defects, and we validate the capacity of the team using the LivePlan feature of Polarion ALM which reveals over- and under- tasked people, potential bottlenecks, and dependencies as soon as we plug our tentative plan into the system.
Normally the User Stories in the Product Backlog are have been inspected by developers in advance, rough estimations have been given, so in the Planning Meeting team members come with prepared questions. BTW, they may also come in with concerns – e.g. if they feel that some functionality may conflict with some agreements or principles, or one described feature is inconsistent with some other.
Artifacts to be discussed during Planning Meeting include:
- Product Backlog Items (User Stories), in order of business demand
- User Stories should be estimated in advance ( by setting its Size in Story Points attribute in Polarion ALM), or if considered to be small, then concrete estimation might be agreed on in the meeting.
There are some preconditions discussed at the planning meeting . We don’t have a team where every developer can do whatever his colleague can do. Almost everybody has their own specialization and sometimes it happens that if a person is on vacation or sick, some area of functionality won’t be addressed efficiently during the sprint. So the team, together with the Product Owner, discuss if it makes sense to delegate the feature to somebody else and have lower performance, or if it will be better to postpone it to the next Sprint, waiting for the right specialist. Of course such issues are resolved on an individual basis.
Artifacts to be composed out of the Planning Meeting:
- Selected User Stories for the Sprint become a Time Point assignment
During the second part of the Meeting concrete tasks are assigned. Results of the planning meeting might be presented in a wiki page (we go directly to the Sprint Board):
Daily Scrums
Scrums might be the most complicated part of Scrum – this requires a change of minds. Too many of us interpret meetings as means of getting tasks and reporting back, but Scrum in general, and Daily Scrums particular, are about helping the team to understand current situation correctly and to be able to adjust if necessary to get the targets done. Daily Scrums allow team members to synchronize, understand as one entity whether Sprint goals are still feasible, if we’re really “right on time” and if not, take decisions about what to change. Nobody should be collecting reports on the meeting, and the Scrum Master should set one simple question and make sure that everybody knows theanswer to it: “Are we sure we’ll meet our Sprint goals? Please show/explain how we do that!”
We use the Sprint Board in Polarion ALM’s integrated Wiki to track progress of our Sprint execution, a really nice and useful Velocity Macro on our active Wiki pages:
We have several teams in our development department working on the same project, and we can easily switch from one team’s Sprint Board to another or see an aggregate overview:
Look useful? The functionality I’ve shown you in the screenshots is provided by the Scrum Project project template, included in all distributions of Polarion ALM 2011.
The Assessment Meeting
Every iteration ends with an Iteration Assessment Meeting, where every developer presents his work, either in the form of a document if the task was to “specify” or “analyze” or “profile”, or as a demo of the work as it has been implemented in the product.
By the Assessment Meeting, the User Story should be already tested by QA and documented (or prepared for documentation). Experience shows that documenting everything implemented in a sprint during the same sprint is not always feasible. For example, if documentation should reflect a feature that is implemented over two or more sprints, or a feature is finished late in the sprint. In the assessment meeting, Doc writers have chance to see how functionality really works and understand the scope of the documentation work. So we have set constraint that all the features implemented in Sprint X must be documented in Sprint X+1.
From a workflow point of view, User Stories are marked as “Implemented” (programming is finished), “Done” (QAed, Documented), “Verified-Done” (when corresponding stakeholder agrees that this functionality is really what he requested and expected).
For the Assessment Meetings we check only those marked as “Done”.
The Retrospective (Lessons Learned)
This is the end-part of the Assessment Meeting. Ideally, it is a time to discuss how we could optimize the process to implement yet more Items over a sprint, but more typically we’re find ourselves trying to assess and identify things that were less than perfect in our process and/or the implementation of some feature during the sprint.
We also try to identify additional synchronization risks, communication problems, involve additional people to show them some dependency, which was not fulfilled, and other subjects we feel we need to discuss.
NEXT…
In the next and final article of the series, I’ll take you inside our daily development and share how we work during each Sprint.
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.
