From Post-Apocalyptic RPG wiki
This article takes a closer look at the different roles in an Agile development team.
The product owner establishes a creative vision of the game, communicates it and takes a lead role in feature prioritization. This said: while in commercial projects there is often a (physical) person who takes take of the product owner role, things are a bit more complicated for PARPG. Due the open source nature of the project, the entire development team can considered to be the product owner. This raises the question who is actually part of the development team, which isn't easy to answer because the line between community members and developers is quite blurry in open source. For now we assume that the entire development team is the (formal) product owner of PARPG. In the future, some developers might focus on the role of product owner but if so, it will be a role that has to be earned by building trust among the developers.
This said: the product owner has these core responsibilities in a Scrum-based project:
- Create a shared vision
- The product owner helps the team to create a shared creative vision. This is critical to the success of the game as it ensures that gameplay and artistic direction actually mesh. The product owner is also the voice of the player who will play the game in the end. He ensures that the departments don't isolate themselves but actually cooperate to create a fun game.
- Own the product backlog
- The product owner manages the product backlog and prioritizes the features. This role is especially important in the entire sprint process. The product owner prioritizes the product backlog during the course of development and especially in sprint prioritization. He participates in sprint planning and sprint review as well.
- Manage releases
- The product owner manages the release plans.
The most important point right away: 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. He has the following responsibilities during a sprint:
- Adressing impediments
- All kinds of problems that interfere with the sprint progress are called impediments in Scrum. By creating cross-discipline teams, the sprint developers are empowered to resolve most of these problems themselves without external help. The sprint coordinator ensures that awareness for impediments is raised so they get resolved. Some impediments can't be resolved within the sprint team. E.g. infrastructure problems will need help by the project management to address them. Sometimes impediments can't be resolved right away. In this case, the sprint coordinator tracks these impediments, keeps the sprint team updated about progress and ensures that they're not forgotten.
- Monitoring progress
- The sprint coordinator tracks the progress and makes sure that the team is aware how well they're performing in the sprint. The twice-weekly Scrum meeting is used to track progress.
- Facilitating planning, reviews & retrospectives
- The sprint coordinator prepares the sprint meetings. This includes scheduling the time, preparing the space (ensuring that the meeting IRC channel is logged) and ensures that the agreed upon time limits are not exceeded.
- Encouraging continual improvement
- The sprint coordinator promotes a culture of continuous improvement. The sprint coordinator has to ensure that the sprint team actually owns the sprint. If he recognizes problems before the team does, he should bring them to their attention and propose a solution. This said: the sprint coordinator should never lead implementing the solution. He should rather help the team to spot these problems and own the solution.
The sprint developers are the people who do the hard work in the trenches.
- Commit to the sprint goal
- Tackle the tasks identified in sprint planning.
- Solve problems as a team
- As the sprint team owns the sprint, they resolve problems as a team. Problems that can't be solved within the team are brought up to the sprint coordinator so he can support the team.
- Create knowledge
- During sprints, the sprint developers created knowledge; usually in the form of documentation. This can be either code documentation that resides within the sourcecode or external documentation that resides at the wiki.
- Help to inspect and adapt
- By reporting back progress and bringing up impediments, the sprint developers supply the most important information. This information is essential to the inspect and adapt cycle.
Sprint interns are newcomers on the team who would like to learn the ropes by actually contributing to a sprint:
- Learning on the sprint
- As most progress will be made in sprints in the future, participating in sprinting will be best way to actually get started and help the team.
- Tackle smaller sprint tasks themselves
- The right balance between empowering sprint interns and acknowledging that they're still new to the team has to be found. Therefore sprint intern will tackle smaller tasks during a sprint.
- Help with bug testing & play testing sprint builds
- While bug & play testing are tasks the entire sprint team will perform, it's a field where sprint interns can provide quite valuable feedback even without expert knowledge in a specific domain.
Scrum teams consist of developers of different discliplines/departments. They work together on reaching the sprint goal. The sprint goal mainly determines what kind of discliplines are required to reach it. E.g. if the sprint goal requires to create new 3d assets, having a 3d artist on the sprint team is essential.
Sprint team size
We've decided that sprint teams shouldn't exceed seven developers. Otherwhise it will become harder and harder to schedule meetings and communication costs will increase in general. Out of seven developers, we will accept up two sprint interns in case the sprint team isn't already full.
Note: for our first sprint, we'll make an exception and won't limit the number of sprint devs to not exclude anyone.
We expect that sprint team members can invest 5-7 hours per week. That means during a 4 week sprint, most developers will work about 20-30 hours on sprint tasks.
Tasks are freely distributed among the sprint team. To ensure that no work is done twice, work in progress and completed tasks need to be tagged in Trac:
- Assign tasks that you're working on to yourself in Trac
- Write sprint task tickets for tasks you're working on that haven't been tracified yet
- Close sprint task tickets that you've successfully tackled; commit the result into the sprint branch in SVN and reference the specific sprint task ticket in the commit message
Product owner & sprint coordinator
The question is often brought up if a sprint coordinator (ScrumMaster) and the product owner should be part of the (core) sprint team. The Scrum answer to it (by the book) is: no. This said: PARPG is an open source project and we will often need every helping hand to reach the sprint goal. The sprint coordinator and product owner have to primarily focus on their responsibilities, otherwhise we won't be able to utilize the full potential of Scrum. Sprint coordinator and product owner can take care of smaller tasks within a sprint if that doesn't lead to neglecting their core tasks.