Agile PARPG development with Scrum

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Infrastructure proposal.png This article covers an infrastructure proposal.

Infrastructure proposals are suggestions how to improve the project infrastructure; this also includes the code toolchain and tools for code documentation. Infrastructure proposals will be evaluated by the project management department and implemented down the line if they have been agreed upon.

This proposals explores if/how applying agile project management concepts like Scrum could help us to stay focused and make reasonable progress on a steady basis. It's now deprecated as Scrum has been already introduced in PARPG development.

Contents

Disclaimer

What is Scrum?

Realistic assessment of Scrum

The good news

The bad news

Scrum concepts

User stories

  • User stories are worded in the language of the stakeholders; this is useful when developers of different departments are communicating as well
  • A user story is a short description of a game (feature), tool or pipeline feature that has a clear value to the user
    • If the user story is about a tool or pipeline feature, the user is actually the developer who uses the tool or pipeline to make the game
  • User stories are created to easily identify the value of certain game features, tools or pipeline feature and commuciate their value for later prioritization
  • Recommend user story format: As a <user role>, I want <goal> (so that <reason>)
    • User role: the person who benefits from the user story; this can be a developer as well
    • Goal: the goal of the story; this a feature or function in the game, tool or pipeline
    • Reason: the benefit to the user when this feature or function is used

Definining done

  • Defining done is based on picking items from the product backlog, add them to the sprint backlog and tackle them in the course of a sprint
  • Product backlog items are based upon fleshed out user stories

5 ways of defining done

  • Game runs on development machine
  • Game runs on one or all target platforms
  • Game runs at a shippable or target frame rate
  • Assets all conform to naming conventions
  • Game runs within the memory budget and has no memory leaks

Product backlog

  • Consists of product backlog items (PBI)
  • PBIs describe features or tools; they can be worded as user stories
  • PBIs are sorted by their priority; high priority PBIs are considered to be tackled in the next sprint
  • PBIs reside in the product backlog until they're moved into the sprint backlog

Sprints

Sprint goal

  • Sprints have a sprint goal; an overall theme of the sprint to which the team commits
  • Sprint goal remains unchanged during the sprint

Sprint backlog

  • PBIs get broken into smaller sprint backlog tasks once they have been chosen to be tackled in a sprint
  • PBI example: The player can jump
  • Associated broken down sprint backlog tasks:
    • Animator: create jumping animations
    • Programmer: implement jumping control
    • Programmer: implement jumping physics
    • Designer: tune jumping

Sprint meetings

Sprint prioritization meeting
  • Sprint prioritization meeting is the place where the product backlog is evaluated and specific PBIs to tackle in the next sprint are discussed to find a potential sprint goal
  • If a PBI is too large to tackle it in a single sprint, the PBI has to be split up into smaller PBIs that can be tackled within one sprint
Sprint planning meeting
  • The sprint planning meeting is the place where the PBIs chosen in the sprint prioritization meeting are broken down into sprint backlog tasks
  • Sprint planning meeting is attended by lead developers and domain specific experts if required to properly tackle the sprint goal

The daily Scrum

Each day the team gathers for the daily Scrum meeting. The daily scrum is quite valuable for these reasons:

  • Synchronize effort among all team members
  • Commit to the work to be accomplished in the next day and reaffirm the team’s commitment to the sprint goal
  • Identify any impediments to be addressed by the team
  • Ensure that all team members are on the same page. All developers should be aware of the problems that some developers face in their specific field of work
  • This way the daily Scrum enables them to micro-steer their progress toward their goal together

The daily Scrum in practice

  • Timeboxed 15 minute meeting
  • Each team member participates in the daily Scrum
  • Each team members answer three questions during the daily Scrum:
    • What have I done since the previous daily Scrum?
    • What am I going to accomplish between now and the next daily Scrum?
    • What are the problems or impediments slowing me down?
  • Daily Scrums are not for solving the problems; the solving process takes place over the course of the rest of the day; this way all important points can be brought up in the timeboxed 15 minutes

Introducing Scrum in PARPG development

  • The product backlog consists of Trac tickets
  • The product backlog items (Trac tickets) should be based upon user stories
  • Sprint prioritization meeting to agree upon a sprint goal
  • Sprint planning meeting to agree upon which product backlogs items should be moved to the sprint backlog
  • Sprints are separate milestones in Trac; all sprint backlog tasks are moved into this milestone; if we adopt this policy we'll have to change our one release per Trac milestone policy if we want to tackle more than one sprint goal per public release
  • If we can't make an informed decision if a sprint backlog task is actually done, we'll need to clarify the sprint backlog task and/or the (code) proposal it is based on
Personal tools