How to sprint
From Post-Apocalyptic RPG wiki
This article explains how sprints work in PARPG development. This article is simply a summary of the other Agile articles that reside at the wiki.
What is a sprint?
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.
Why sprint at all?
Sprints generate value. This can be code, assets & knowledge/documentation.
What happens during a sprint?
Sprints are holistic in the sense that tasks as writing unit tests, debugging, optimizing, playtesting and polishing is actually part of a sprint and not deferred to a later point in development.
A sprint goal is the overall theme of a sprint. The sprint team commits to this goal. The sprint goal is based on the product backlog item(s) you plan to tackle during the sprint.
Sense of ownership
Sprint teams own the sprint goals and the associated tasks they are working on in a sprint. The sprint team decides how many user stories they can tackle in a sprint and decide how to tackle them.
The sprint timeframe is agreed upon during sprint planning. Sprints in PARPG range from 2 to 4 weeks. If we can't tackle a sprint goal within 4 weeks, the PBIs were simply too massive to tackle within one sprint. In this case we have to document this in the sprint review to and learn from it by splitting up massive PBIs into smaller ones in the future.
Sprints development takes place in an SVN branch. This way we won't have to worry about introducing larger changes that might break trunk.
- When should the twice-weekly meeting take place?
- What kind of talking order should we have?
Cross-discipline teams. The sprint team takes ownership over the sprint goal.
For more detailed information about the different roles on the sprint team, check out: Sprint team.
- No traditional lead or management role
- Just a fancy term for the ScrumMaster on the sprint team who will help to coordinate the sprint
- Educate the team about Scrum
- Nurture sense of ownership within the sprint team
- Ensure that impediments are addressed
- Monitor the sprint progress
- Facilitate sprint planning, review and retrospectives
- Encourage continual improvement of the processes and workflows
- Help the sprint coordinator to prepare the sprint backlog
- Commit to the sprint backlog tasks
- Report progress and impediments to the sprint coordinator so he can factor this information in and resolve impediments that are slowing the sprint team down
- Learning on the sprint
- Tackle smaller sprint tasks themselves
- Help with bug testing sprint builds
- Provide feedback based on play testing
- Should not slow down the other sprint developers
Self selecting sprint teams
The sprint teams do not only own the user stories and the tasks they work on, they also own sprint team membership.
If interesed sprint developers and/or inters have repeatedly ignored agreed upon sprint guidelines and/or sabotaged reaching the sprint goal in other ways, the sprint team can refuse to accept these developers/interns in future sprints. The same goes for ongoing sprints: if developers/inters sabotage reaching the sprint goal, the sprint team can remove them from the sprint as last resort. This should hopefully not be necessary in reality though. If this situation arises, the sprint team should consult the sprint coordinator to help resolve the issues.
Three sprint phases
- Research if spikes would be necessary/useful to reduce the risk of having to cancel a badly planned sprint
- Sprint prioritization & sprint planning meeting
The twice-weekly Scrum
- Progress report
- The daily Scrum in a distributed team environment
- Sprint review
- Sprint retrospective
Completed & canceled sprints
As we will classify PBIs as either essential or optional during sprint prioritization, the team will primarily commit to the essential PBIs during the sprint. This will help us to successfully complete a sprint even if we won't have the time to tackle a single optional PBI during the sprint. In some rare cases, a sprint might have to be canceled nevertheless. This could happen in theory if a sprint goal hasn't been properly scouted and we run into major problems that we didn't foresee. In this case we have to consider to cancel the sprint, have a retrospective to find out what went wrong and start a new sprint with a different sprint goal after that. Canceling sprints will hopefully be not necessary in reality as spikes can help us to scout potential problems before commiting to a sprint goal.
As sprints demonstrate created value, we should share them with the community as sprint snapshots. This needs to be balanced so that sprints don't turn into full featured releases with all the possible release overhead. One possible way to tackle it to provide sprint source tarballs but to avoid compiling binaries for different platforms. Furthermore sprint snapshots might be just announced at our development blog while official releases will be bound to a larger public relations effort to spread the word about them.
- Agile game development checklist: http://www.clintonkeith.com/resources/AGD_Checklist.pdf
- How to fail with Agile: http://www.clintonkeith.com/resources/HowToFail.pdf
- Scrum checklist: http://www.stuq.nl/media/file/scrum-checklists.pdf