From Post-Apocalyptic RPG wiki
This article what sprint-related meetings there are why they're useful for us.
Why have sprint meetings?
Sprint meetings are essential to the inspect and adapt approach. Sprints have to be properly prepared (by priorizing the product backlog), we need to know what kind of tasks are necessary to reach a sprint goal and we have to keep track of progress and be aware of impediments that are slowing us down. Furthermore we have to learn from what went well and what could be improved.
The sprint prioritization meeting is the first meeting of the sprint cycle. During this meeting, the high priority product backlog items (user stories) are reviewed and a sprint goal is selected. The product owner describes the highest priority PBIs and the sprint team has the chance to ask design-related questions. If PBIs on the product backlog are too large to be tackled within a sprint, they're broken down into smaller PBIs that fit into a single sprint.
After the high priority PBIs have been reviewed, the sprint team discusses the potential sprint goal for the upcoming sprint. The composition of the sprint team plays a large role in this case. The sprint team can only commit to sprint goals that actually suit the current composition of the sprint team. E.g. if there are no graphics artists on the sprint team, the team can't commit to a GUI-related sprint goal. If PBIs depend upon other PBIs that aren't planned to be tackled within the same sprint, the PBI should be skipped altogether and not tackled within a sprint before the PBI it depends on has been actually tackled.
In sprint prioritization, enough PBIs should be discussed so that the sprint team has the chance to chose from them. Due the volunteer nature of PARPG, we'll have to tweak things a bit in this regard. We will chose a smaller number (rule of thumb: 2) of high priority, essential user stories we want to commit to during a sprint. Besides that we'll also identify a slightly larger number (rule of thumb: 3-4) of lower priority, optional user stories. We'll commit to the implementing these user stories in case we've already finished the work on the essential user stories during the sprint and there is still time left to work on something.
In Sprint planning, the team takes a look at the PBIs that were chosen in sprint prioritization and further breaks them down into tasks that form the sprint backlog. The team discusses design and implementation details for every PBI to identify potential problems early. The product owner should be around to ensure that the team can ask if questions about design details arise that might influence the specific sprint tasks.
After that each PBI - starting with the highest priority PBI - is broken down into tasks that should exceed 8 man hours of work. We'll need to estimate a bit there: if a sprint team member raises concerns that a sprint task is too large and should be broken down into smaller tasks, we can use a simplified form of planning poker to estimate the "task size". If it turns out that the task is indeed too large, it gets broken down into smaller tasks. Tasks are usually department-specific. After all PBIs have been broken down into tasks, the sprint planning meeting is over and the team can start to commit to these sprint tasks.
In a commmercial, fulltime job, paid environment task estimation plays a large role. This said: PARPG is an open source volunteer project. As developer commitment is hard to estimate in advance, we shouldn't spend too much time on task estimation.
The twice-weekly Scrum
In fulltime Scrum projects the developers meet once a day for 15 minutes (timeboxed) in a meeting called the daily Scrum. They answer three basic questions in these daily Scrum meetings:
- What have I done since the last daily Scrum?
- What am I going to work on next until the next daily Scrum?
- What are the impediments that slow me down?
This daily Scrum is not for problem solving. Problem solving happens between these meetings. It's the job of the sprint coordinator (ScrumMaster) to ensure that side conversation are kept to a minimum.
It won't be possible to have daily meetings with a distributed team that is spread around the entire world. Therefore we'll modify the daily Scrum concept and rather have twice-weekly Scrum meetings. As the meetings will take place at our IRC channel and IRC communication isn't as effective as face to face communication, our twice-weekly meetings aren't timeboxed to 15 minutes but to 30 minutes!
If a sprint developer can't attend a twice-weekly Scrum meeting he simply gives his progress & impediment report at the sprint boards of the forums. These boards are also used to report back progress & impediments in the time between the twice-weekly Scrum meetings. The actual timeslots (day & time) for the twice-weekly meetings still has to be agreed upon.
Sprint review takes place during the last day of a sprint. The sprint team will sit together and actually enjoy the fruits of their labour by playtesting the final sprint build. Community members can be invited to playtest the sprint builds together with us and give us immediate feedback. Sprint reviews focus on reviewing the features we worked on during a sprint.
This final sprint build will be tagged in SVN, a sprint snapshot will be released and the branch will be merged back into the SVN trunk. The blog will be updated with information about the sprint and a link to the released sprint snapshot.
Sprint retrospectives are quite important to the inspect and adapt cycle. To continually improve, the sprint team will meet and answer these three questions:
- What things should we stop doing?
- What should we start doing?
- What things are working well for us, so we should continue to do them?
Sprint retrospectives are focused on reviewing the sprint process and learning from this insight via the inspect and adapt cycle.
- Scrum meetings: http://scrummethodology.com/scrum-meetings/