From Post-Apocalyptic RPG wiki

Revision as of 00:54, 2 February 2011 by MvBarracuda (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Glossary.png This article is a glossary!

This article lists agreed upon terms to ease communication. Glossary articles are primarily targeted at the developers of PARPG; either developers of a specific department or the whole team in general.

This glossary contains all sprint-related terms developers who contribute to the sprint should be familiar with.


What should be part of this glossary?

  • Scrum and Agile concepts that are used in PARPG development

What shouldn't be part of this glossary?

  • Terms already explained in other glossaries at the wiki
  • Scrum and Agile concepts that we aren't using in PARPG development

Agile terms


Also called epic user stories. They're too large to be tackled within a single sprint. They reside in the product backlog until they're considered to be tackled in a sprint. If they're chosen, epics are broken down into smaller PBIs that actually can tackled within a sprint.
Impediment backlog
The impediment backlog is a prioritized list of tasks the sprint coordinator takes care of to support the sprint team.
Product backlog
The product backlog is a prioritized list of user stories (PBIs) that reside in a separate Trac milestone. The product backlog is one of the most important - if not the most important - tools of a Scrum project.
Product backlog item
Also called PBI. Product backlog items - often expressed as user stories - are game features, tools of the asset pipeline or proposed infrastructure improvements that have a certain priority to the product owner. This priority is based on the value, cost, risk and knowledge factors.
Release plan
The release plan is a list of larger features that we consider to tackle for the next release. While some Scrum projects have a separate release backlog, most projects - including PARPG - simply have a release plan that is constantly updated as the game emerges.
Sprint backlog
A sprint backlog is a list of tasks that are needed to be tackled within a sprint to reach the sprint goal. It also contains the user stories the team tackles in a sprint, as well as sprint-related bugs.
Tasks are simply the tasks the sprint team works on during a sprint. In sprint planning, the team breaks down the chosen user stories into tasks.
User stories
User stories are a specific form of feature requests that can be used to fill the product backlog. User stories usually follow this format: As a <user role>, I want to have <goal> [so that <reason>].


Sprint prioritization
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.
Sprint planning
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.
Sprint retrospective
Sprint retrospectives take place after a sprint. They are focused on reviewing the sprint process and learning from this insight via the inspect and adapt cycle.
Sprint review
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. The sprint team members can give feedback on the improvements implemented during the sprint.
The twice-weekly Scrum
A twice-weekly timeboxed (30 minutes) meeting to report back progress and bring impediments to the attention of the sprint coordinator. The meeting is not for problem solving; this takes place between the twice-weekly Scrums! In a commmercial environment, these Scrum meetings usually take place on a daily basis and are timeboxed to 15 minutes.


Conditions of Satisfaction
Also called CoS. Conditions of Satisfaction are sometimes added to user stories that get tackeled in a sprint so the team can decide if a feature has actually been completely implemented and can considered to be done. These CoS are usually added to the user story when it's moved from the product backlog into the sprint backlog. CoS have to be testable.
Definition of done
Definitions of done are criteria that simply help us to decide if we reached our sprint goal; therefore they are an essential part of the development process.
Hard spike
These spikes are embedded into ongoing sprints. They can be used to prototype different concepts within a sprint and decide afterwards - based on the created knowledge - which concept to implement in the sprint in the end. These spikes are strictly timeboxed.
Impediments are problems that are slowing the sprint team down. If these problems can't be easily resolved within the sprint team, the sprint coordinator takes control over them to support the sprint team.
Soft spike
These spikes are tackled while the sprint still gets prepared and work on it hasn't officially started yet. Sprint preparation spikes are useful if going into sprint right away might be very risky as their is a lack of knowledge that should be addressed first. These spikes are not timeboxed.
Sprints are iterations of development where the sprint team commits to a specific sprint goal. During the sprint, the sprint team produces vertical slices of functionality. Sprints are timeboxed.
Sprint goal
A sprint goal is the overall theme of a sprint. The sprint team commits to this goal. The sprint goal is based on the PBIs you plan to tackle during the sprint.


Product owner
The product owner establishes a creative vision of the game, communicates it and takes a lead role in feature prioritization. He creates a shared vision, owns the product backlog and manages releases.
Sprint coordinator
The sprint coordinator is no traditional lead or management role. It's simply a fancy term for the ScrumMaster on the sprint team who will help to coordinate the sprint by addressing impediments, monitoring progress, facilitating sprint meetings and encouraging continual improvement.
Sprint developer
The sprint developers are the people who do the hard work in the trenches by commiting to the sprint goal.
Sprint intern
Sprint interns are newcomers on the team who would like to learn the ropes by actually contributing to a sprint.

Additional reading

Personal tools