How to sprint

This proposal explores how sprints should work in PARPG development.

Why sprint at all?
Sprints generate value. This can be code, assets & documentation.

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 product backlog item(s) you plan to tackle during the sprint.

Sprint timeframe
The sprint timeframe is agreed upon during sprint planning. Sprints usually range from 2 to 4 weeks in a commercial fulltime job environment. They use hard timeboxing: that means that the duration of a sprint should not be extended. As PARPG is a volunteer project and commitment can vary from developer to developer depending on his current workload outside the project, we should apply changes to the classical sprint approach.

Sprints in PARPG should range from 3 to 6 weeks. If we can't tackle a product backlog item within 6 weeks, the PBI was 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.

Sprint team
Cross-discipline teams. The sprint team takes ownership over the sprint goal.

Sprint coordinator

 * Prepare the sprint by taking a PBI from the product backlog and breaking it down into sprint backlog tasks with the help of the sprint developers
 * Resolve impediments that the sprint team can't address themselves
 * Comparable to the role of the Scrum master in a Scrum environment

Sprint intern

 * Learning on the sprint
 * Help with testing sprint builds
 * Should not slow down the other sprint developers

Self selecting sprint teams
If interesed sprint developers and/or inters have vastly slowed down the progress in previous sprints and/or sabotaged reaching the sprint goal in other ways, the sprint coordinator can refuse to add developers/interns to the sprint team in the first place. The same goes for ongoing sprints: if developers/inters sabotage reaching the sprint goal, the sprint coordinator can remove them from the sprint as last resort. This should hopefully not be necessary in reality though.

What is a spike?
Sometimes it's really hard to know the value, risk or cost of a feature in advance. You simply need more information about the feature to realistically judge it. In this case you can create a timeboxed user story for a prototype or an experiment and add it to the product backlog. These timeboxed stories are called spikes. An example for a spike would be the evaluation of a GUI library to find out if it makes sense to use it in a GUI-related sprint later. If it turns out during the spike that the GUI library of choice doesn't work well for the requirements of the project, alternative GUI libraries might have to be evaluated before a GUI-related sprint can start. Spikes just produce knowledge that is yet very valuable to the team as it greatly helps to reduce risks. Spikes are a good way to scout potential problems before moving into a sprint. This way they can be used to prevent that an ongoing sprint would have been canceled otherwhise.