Polarion goes Scrum (Part 5)

Sprint Meetings

Meetings are possibly the most important assets of Scrum. As described in previous chapters, Scrum allows us to identify problems and help find ways resolve them. Meetings are the essential part when team commits to Product Owner on the amount of work (features) they will address over the sprint, they discuss the progress on Daily Scrums and, finally, access results on the end meeting.

In this post and the next I’ll describe how we manage those meetings with the Polarion development team.

Planning

The goal of the Planning Meeting is to ensure 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, ensure 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 User Stories, Tasks, Improvements, Defects and validate 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 Initial Estimate 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 checked and also remaining estimates for the User Stories are clarified.

Results of the planning meeting are presented in a wiki page:

Daily Scrums

Daily 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 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 the answer to it: “Are we sure we’ll meet our Sprint goals? Please show/explain how we do that!”

In our situation arranging of Daily Scrums is relatively easy – our teams are small and we adjust the meetings to the lunch hour :-). This gives us even more flexibility on discussing implementations, answering on questions, etc. When the most important questions are answered the team may go to lunch and discuss very low level details, if needed.

We use the Wiki Task Board to track progress of our Sprint execution, a really nice and useful Velocity Macro on our Wiki Active Pages in Polarion ALM:

Assessment

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 eventually documented. Reality shows that documenting all things together, as well as functional testing of complex environment to full extend is not always possible. For instance, if documentation should reflect several features and only one of them is already fixed. We use special a User Story “UNDONE: release X.Y.Z” to link all the things to be addressed in Stabilization Sprint before corresponding release.

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”. For User Stories which have some lacking documentation (see “UNDONE” above), we still mark the particular User Story as “Done”, taking in account completion of documentation in Stabilization Sprint.

As input for Assessment meeting we use yet another, more compressed, variant of the Task Board:

Retrospective (Lessons Learned)

This is the end-part of the Assessment Meeting. In an ideal situation 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 implemented in the sprint.

We also try to identify additional synchronization risks, problems of communication, involve additional people to show them our dependency, which was not fulfilled, and other subjects.

Next time…

In the next post I’ll talk about Sprint development and how the Polarion development team manages their process.

---

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.