From Post-Apocalyptic RPG wiki
This article explains the different artifacts that are common in Scrum projects and how we utilize them for PARPG.
What is a product backlog?
The product backlog is a prioritized list of user stories that reside in a separate Trac milestone.
Why maintain a product backlog?
Agile projects maintain a product backlog for these reasons:
- The user stories can be easilizy prioritized; this way the team always knows what the most important features are and can work on them
- It supports planning throughout the entire lifecycle of the project; user stories can be tackled, new ones can be added and outdated ones can be removed as the game emerges
- The prioritization helps to give the community a good idea into which direction the project is going
Product backlog items
The product backlog consists of a number of product backlog items - often simply shortened as PBIs. At PARPG, user stories are used as PBIs to fill the product backlog.
Maintaining the product backlog
Before a sprint starts, the product owner checks out the product backlog and prioritizes its PBIs. This is usually done with the help of the other developers and the community. There are four main factors that have to be taken into account when prioritizing the product backlog:
- Every user story has a value. Some user stories are more valuable than others, either to the potential players of the game or to the development team that benefits from asset pipeline and infrastructure improvements.
- In commercial projects the cost factor is quite important when prioritizing the product backlog. This said: while we don't spend money on the development of the game directly due the volunteer nature of PARPG, there is an important cost factor nevertheless. Time. If a features sounds quite awesome on paper but would take ages to develop, it's prolly not worth spending our time on. The same goes for asset pipeline tools and infrastructure improvements.
- Risk implies uncertainty about the value and cost factors of a PBI. User stories with a higher risk are usually prioritized higher. This way high risk PBIs are often explored early in spikes to reduce the risk by creating extra knowledge.
- If the product owner can't judge the value, cost or risk of a PBI, they can add a spike to the product backlog to explore a field in more detail and create knowledge this way.
Splitting up PBIs
At the beginning of a project, the product backlog mainly consists of epics. These epic user stories are too large to be tackled within one sprint. In sprint prioritization, the epics are prioritized and the highest priority epics are broken down into smaller user stories that are potential sprint goals for the upcoming sprint.
To keep the product backlog clean and reserve it for user stories only, bugs reside in a separate backlog, often called the Defect backlog in Scrum projects. This defect backlog will be simply a milestone in Trac that contains the bug reports as Trac tickets. When we plan to address a bug in a sprint, the bug report gets moved into the sprint backlog. After the last sprint of a release has been tackled, the team will often take a look at the defect backlog and consider to fix some of the bugs from the defect backlog to add some extra polish to the release. The bugs that are planned to get addressed before shipping the release will be moved into the release plan, which is simply another milestone in Trac for us.
Some Agile projects use a release backlog for user stories they plan to tackle in a specific release. Most Scrum projects abstain from having a separate release backlog and have a release plan instead; that's how we will handle it for PARPG as well. After a major release has been shipped, the team will sit together in its first sprint prioritization meeting after the release and discuss the plans for the upcoming release as well. We don't have to plan too far ahead: it's far more important to agree upon a first sprint goal for the new release. After the first sprint has been finished, more release feedback will have been trickled in, which should give us a good idea what the community would like to see in the game. This feedback can help us to pick a proper sprint goal for the second sprint of a release.
What is a sprint backlog?
A sprint backlog is a list of tasks that are needed to be tackled within a sprint to reach the sprint goal.
Why maintain a sprint backlog?
The sprint backlog helps the team to stay focused on the sprint goal. As the tasks on the sprint backlog are prioritized, it's easy to see which tasks are most important and should be tackled first in a sprint.
Sprint backlog items
Besides the actual tasks to work on in a sprint, the sprint backlog also contains two additional sprint backlog item types:
- User stories that form the sprint goal. Whenever a user story is chosen for a sprint in sprint prioritization, it gets moved into the sprint backlog and is prioritized according to its importance. High priority user stories are considered to be essential for reaching the sprint goal. The team commits to tackling these user stories (and the associated tasks) first in a sprint. Lower priority user stories are considered to be optional. The team commits to tackling these user stories after the essential ones are already implemented and if there is still time left in the sprint. User stories that reside in the sprint backlog often feature conditions of satisfaction. These CoS are an important tool to judge if a user story has actually been successfully implemented.
- Sprint related bugs: Bugs that are related to the sprint or are found during the sprint are added to the sprint backlog as well. As bug fixing is part of the sprint process, the team commits to fixing these bugs in the sprint. In case complex bugs are found that can't be addressed in the sprint directly, a but report is filled nevertheless. The bugs that couldn't be fixed during a sprint and still reside in the sprint backlog at the end of the sprint are moved into the defect backlog.
Maintaining the sprint backlog
The team and the product owner decide together which PBIs are essential and which ones are optional sprint goals. During the sprint, the sprint team takes ownership over the sprint goals and commits to them. Tasks are freely distributed among the team and the sprint backlog is updated so it's clear to see:
- Which user stories and tasks are currently worked on
- Which user stories and tasks have already been completed
- Which user stories and tasks are still unstarted
Trac milestones & Scrum artifacts
These different Trac milestones/milestone types are used for PARPG development:
- Product backlog milestone: will contain Trac tickets in the form of user stories.
- Evaluation milestone: new tickets filed by community members reside in the evaluation milestone until a (lead) developer had the time to review them. In case the ticket is a feature request, the reviewer rewords the feature request as user story and adds it to product backlog. If the ticket is a sprint-related bug, it gets added to the sprint milestone. If it's a bug that isn't related to an unstarted or ongoing sprint, the ticket is added to the bug milestone.
- Defect backlog milestone: as the product backlog is reserved for actual user stories to better prioritize them, bugs (that are not linked to a sprint goal) will reside in a separate bug milestone. Such bug milestones are often called Defect backlog in Scrum projects.
- Sprint milestones: will contain Trac tickets in the form of tasks and bug reports that are closely related to a sprint in preparation, or an ongoing sprint. This way, the sprint milestones contain the complete sprint backlog.
- Release milestones: release milestones map to actual public releases of PARPG. Release specific tasks reside here: compiling packages for different platforms, release PR, etc. Furthermore release milestones often contain bugs that have been moved from the defect backlog into the specific release to indicate that the team wants to fix these bugs before shipping the release.
- How to prepare the product backlog for sprint planning: http://www.agilejournal.com/articles/columns/column-articles/2719-getting-the-product-backlog-ready-for-sprint-planning