Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Agile development basics
Agile development methodology values:
● Individuals and interactions over processes and tools
● W...
Production cycle:
Pre­production is the exploration of what a game is, so biggest challenge is to find the fun of
the game...
According to these stages as the game is developed, the team might find itself in a position of
going through each milesto...
Why Agile Game Development?
Knowledge is key ­ game development is primarily about learning what to make and how to
make i...
Agile values in game development:
●

Individuals and interactions over processes and tools:

The main goal is to promote t...
getting near completion.

Agile game development flow
From left to right, studio management (stakeholders) and customers, ...
Scrum roles

Stakeholder(s) ­ define many of the items in the product backlog and work with the product
owner to prioritiz...
features. Also is often considered the “lead customer” as a voice of the end users, even though
he’s part of the team. The...
the team to see and own the solution to the issue.

The big picture
A game made with Scrum makes progress in 2­4 week iter...
in the development process. scrum meeting enable teams to respond quickly to daily issues.
­ Emergence: As the game is dev...
Releases ­ are a set of sprints meant to bring the game with major new features to a
near­shippable state. A typical relea...
Prioritization ­ this is where the team meets to set the sprint goals for the high priority items on
the backlog with the ...
Sprint meeting:
●
●
●

What have I done since the last meeting?
What am I going to accomplish for the next meeting?
What a...
completes one or sometimes more stories per sprint. Usually the stories are formulated in this
manner:
As a <user role>, I...
evaluate the cost of other stories. Example:
“As a product owner I want to see a mock­up video/animation of how our fighti...
●

Value ­ the value that the story has for the player is the primary criteria in determining the
priority of that story o...
every sprint and complete it through whatever means necessary
● Self­organization ­ enables team to have a degree of autho...
●

Vision changes over time ­ documents are poor databases of change. Don’t expect team
members to revisit the design docu...
Upcoming SlideShare
Loading in …5
×

Agile game development with Scrum

4,412 views

Published on

The basics od Scrum methodology for Game development.

  • This is your last chance to grab all 16,000 plans at this discount price. I've been told that Ted will only extend this offer until midnight tonight and this offer will NOT be repeated again. ➽➽ https://t.cn/A62Ye5eM
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Agile game development with Scrum

  1. 1. Agile development basics Agile development methodology values: ● Individuals and interactions over processes and tools ● Working software over comprehensive documentation ● Responding to change over following a plan ● Customer collaboration over contract negotiation These values have enabled agile frameworks such as Scrum, Lean, Extreme Programming etc. Game development challenges Feature creep ­ a term given to features being added to a project after the original scope is defined.  This happens for two reasons; the first is when the stakeholders see the game in progress and request new features (so­called emergent requirements); two when  a feature doesn’t live up to its expectation so more work is added to find the fun. Feature creep and changes are inevitable. This is often the main problem with writing big designs up front (BDUF): the goal is to answer all the questions about the game. The truth is we can’t know everything about the game at the start. Knowledge comes only when we get the controller in hand and start playing the game at a decent frame rate on the target machine/platform. The only way to recognize the fun is to play it. We may be certain we’re making a first person shooter, but knowledge of exactly what types of weapons are best is lacking. We learn more and reduce the uncertainty as we shoot the characters in the game. Over­optimistic schedules ­ Task estimation is not an exact science. Many things throw off the estimated time to complete a task: ● The difference in experience and productivity between people working together on a single task ● How many other tasks a person is working on at the same time ● The stability of the build and tools used to complete the task ● The iterative nature of the task; its uncertain how many iterations will be necessary for tuning and polishing a feature to “find the fun” Controlling idea ­ A controlling idea is a bit similar to a business statement, but more directed at game features. It’s objective is to capture the essence of what the game is and where the fun factor is. The controlling idea’s essence  and strength is in laying boundaries and goals. Whenever the team is faced with a choice of “should we add this” or “does this fit” they go back to the controlling idea and typically find the answer.
  2. 2. Production cycle: Pre­production is the exploration of what a game is, so biggest challenge is to find the fun of the game that will drive the entire production. Production is a stage where the team fleshes out the story and surroundings to leverage the mechanics created in pre­production. The challenge of production is to maximize efficiency, minimize waste and create predictability. Concept ­ basic description of the game idea and mechanics that could be developed into a full game Prototype ­ a working/playable version of the concept that allows for the user to feel the game mechanics and find the fun in the game, which proves if its worth developing further. Pre­production ­ preparing the game design documentation based on the prototype and user feedback; working out what is the fun factor of the game and  figuring out the game around it. Production ­ making all the designs, code, assets, animation and everything necessary for the releases during the production. Post­production ­ release, marketing, promotion and post­mortem for the game.
  3. 3. According to these stages as the game is developed, the team might find itself in a position of going through each milestone (in waterfall methodology) and reaching the set goal only to realise they’d rather be somewhere else with no time left to change much. By applying the scrum method through iterative game development the goal will reflect the changes during the production so that the time
  4. 4. Why Agile Game Development? Knowledge is key ­ game development is primarily about learning what to make and how to make it. It’s about reducing uncertainty over time. Agile development focuses on building knowledge about value, cost and schedule and adjusting the plan to match reality. Knowledge is created every day. Cost/Quality ­ costs can easily run high when developing a game, so it’s no wonder that most games fail to break even! More cuts made on the resources used to develop a game reduce the fun quality of the game. Finding the fun! ­ a benefit of iterative development is to develop a product in small steps and incrementally add features that add the most value to the game in the fastest and most economical way. “Finding the fun” is the mantra of any iterative and incremental game development project. The agile project curve approaches development in a value first approach. Eliminating waste ­ by finding the fun first, the team is able to find the value early in the project rather than trying to retrofit it at the end. Simple iteration enables game developers to explore more ideas. This makes it possible to enact the kill­gate model, where a dozen ideas are launched and narrowed down until the best remain. Finding the fun:
  5. 5. Agile values in game development: ● Individuals and interactions over processes and tools: The main goal is to promote the team(s) to solve many of the production problems on their own. They manage the smallest details but none of the highest levels. They unburden the leadership of managing minor details and enable them to focus on the big picture. ●  Working/fun game over detailed documentation Some form of design documentation is necessary, but detailed documents create work that is not necessary so much of the work is wasted in the end. If the game follows a detailed plan up­front it won’t be the best game possible. ● Responding to change over following a strict plan The agile approach is to plan what is known and to iterate against what is unknown. Structure of an agile project An agile project is composed of a series of iterations of development. Iterations are short intervals of time, usually 2­4 weeks, during which the game makes progress. Developers implement individual features that have value for the end customer each iteration. These features are called (user) stories. Iterations include every element of game development that takes place in an entire game project: ● ● ● ● ● ● ● Concept Design Coding Asset creation Debugging Optimizing Tuning and Polishing Agile project make steps toward a goal. The point is to use the “inspect and adapt” cycle achieve better results sooner through the ability to steer the plan toward a more desirable goal, rather than sticking to a strict plan and reaching the goal and then desiring to be somewhere else. The game is reviewed at the end of every iteration, and the results influence the goal of future iterations. This is the so­called “inspect and adapt” principle. Every 4 iterations the game is brought to a release (build), which means the major goals are accomplished and the game is
  6. 6. getting near completion. Agile game development flow From left to right, studio management (stakeholders) and customers, identify the features and other requirements (tools and infrastructure needs) for the game. These features are placed on a list ­ Product backlog, that is prioritized by the Product owner. These product backlog items, (PBI’s) are expressed as stories that communicate the value of each PBI to the customer and stakeholders. Scrum teams commit to completing one or more stories from the product backlog every iteration (this is called a sprint.), and demonstrating them in an improved version of the game in each subsequent release (build) of the game. A Scrum master assists each Scrum team, helping them improve impediments to progress and ensuring that they are following the agreed progress.
  7. 7. Scrum roles Stakeholder(s) ­ define many of the items in the product backlog and work with the product owner to prioritize the backlog. These are some of the common stakeholder roles: ­ Publisher/producer ­ Marketing people ­ Studio management Product owner ­ establishes and communicates the vision of the game and prioritizes its
  8. 8. features. Also is often considered the “lead customer” as a voice of the end users, even though he’s part of the team. The product owner is responsible for: ­ Managing the ROI of the game: he’s responsible for ensuring that the investment in the game is returned with a profit which requires extensive knowledge on what the market wants. ­ Establishing a shared vision of the game: he’s a single voice for the vision that is shared with the team in order to ignite creativity and ownership with the team and collaborate with them as the vision evolves with the emerging game. ­ Knowing what to build and in what order: he owns the product backlog and determines the order of features on the backlog. This order determines the order in which those features are developed. ­ Creating release plans and establishing delivery dates: he manages release plans based on changes to the goals or the progress from the team during sprints. ­ Supporting sprint planning and reviews: ● Establishing and updating the features on the backlog and their priorities ● Participating in sprint planning ● Accepting or rejecting the results of the sprint in sprint reviews ­ Representing the end user/player: he makes sure the game has the necessary value for the end user. Scrum master ­ His role is to make sure the scrum is a success and he must apply the principles of scrum and guide the team through the practices. Scrummaster is responsible for: ­ Ensures impediments are addressed: the scrummaster tracks all impediments discovered in the development process (bugs, crashes, meetings without results, constant distraction to the process, progress of each individual on the team on particular tasks...) ­ Monitors overall progress: he makes sure the team knows how well they’re performing against their current goal on a daily basis. If they’re behind the schedule the team is informed as soon as possible. ­ Facilitates planning, reviews and retrospectives: prepares all team meetings, agendas and makes sure the time limit is agreed on for each meeting. ­ Helps the team communicate and improve performance: even with the most productive team the scrum master seeks new ways of getting more out of them. He might recognize problems ahead of the team but should never lead with implementation the solution but rather guide/allow
  9. 9. the team to see and own the solution to the issue. The big picture A game made with Scrum makes progress in 2­4 week iterations, or sprints, using cross­disciplined teams of 6­10 people depending on the need to complete a sprint. at the start of a sprint, during the sprint planning meeting, the team selects a number of features from the product backlog.  The team then estimates the tasks required to implement each PBI into a sprint. The team only commits to features in a sprint they judge to be achievable. Sprint meetings (daily scrum) can be held daily or 2­3 times a week, but are always limited to 15 minutes (timebox) where the team shares their progress or any impediments in their work. Timebox is a fixed amount of time given to a meeting or a task. The 15 minute timeboxed meeting will end at the 15­minute mark regardless of whether all the agenda items are addressed, which pushes the team to be as short and to the point in a meeting as possible. The principles of Scrum As a framework Scrum is meant to have practices added and changed as teams and products evolve. ­ Empiricism: scrum uses an “inspect and adapt” cycle that enables the team and stakeholders to respond to emerging knowledge and changing conditions in real time using actual data gained
  10. 10. in the development process. scrum meeting enable teams to respond quickly to daily issues. ­ Emergence: As the game is developed we learn more about the game and what makes it fun, what is possible and how best to create it. Scrum practices don’t ban designs from being developed upfront. They acknowledge that we can’t know everything about a game from the start. ­ Timeboxing: Scrum is iterative. it delivers value on a regular basis and enables stakeholders and developers to synchronize and micro­steer the project as value emerges. Sprints are an expression of this timeboxed practice. ­ Prioritization: Some features are more important to stakeholders and customers than others. Rather than approaching the development of a game by “implementing everything in the design document”, Scrum projects develop features for a game based on their value to the player who will buy the game. This is what the product backlog is for. ­ Self­organization: Small, cross­discipline teams are empowered to organize their membership, manage their process, and create the best possible product within the timeboxes. They use the “inspect and adapt” cycle to continually improve the work. Scrum parts Product backlog ­ a prioritized list of the requirements or features for a game or the pipeline for making a game. Example: ● Add a new character/enemy on the second level ● Add a particle effect to the game ● Add online gameplay The product backlog is allowed to change after a sprint. PBI’s that weren’t anticipated are then added, those that aren’t necessary are removed and the priorities changed if necessary. The value of every feature is measured in terms of how valuable it will be to the player. This minimizes work based on assumption. The most valuable items in the backlog are broken down into smaller features to fit into a sprint that the team can handle. Sprints ­ a scrum project makes progress in sprints, which are in effect the heartbeat of the entire project. sprints have a fixed duration 2­4 weeks (can be shorter if necessary) and the team commits to the PBI’s they can complete in a single sprint. Sprints produce vertical slices of functionality, sort of like mini­projects on their own that contain everything necessary to get the game to a shippable state (coding, design, asset creation, debugging etc.)At the end of a sprint the team has a new build of the game that demonstrates that the sprint goal was reached.
  11. 11. Releases ­ are a set of sprints meant to bring the game with major new features to a near­shippable state. A typical release lasts between 1­2 months, sometimes more. Sprints Planning ­ the stakeholder, scrummaster and product owner meet with the team to groom the backlog and identify the sprint goal. The sprint planning meeting creates the sprint backlog that defines the work that the team commits to completing buy the next sprint review.
  12. 12. Prioritization ­ this is where the team meets to set the sprint goals for the high priority items on the backlog with the product owner describing the features on the backlog that the team needs to understand in order to evaluate. This is where the team raises questions, concerns about details and requirements for each item. If the items are too large for a single sprint they are broken down into several PBI’s that can fit into sprints.
  13. 13. Sprint meeting: ● ● ● What have I done since the last meeting? What am I going to accomplish for the next meeting? What are the problems slowing me down? Sprint review: ● What things should we stop doing? ­ Practices that have brought problems in the dev process ● What should we start doing? ­ Practices that help the dev process ● What is working well for us? ­ Practices that we should continue in the process Sprint resets When the sprint that the team started working on doesn’t seem achievable for a variety of reasons (sprint goal needs to change, running out of time, wrong estimate etc.) the team has 3 choices: 1. Work overtime to make up for the difference 2. Negotiate with the product owner to remove one or more of the lower priority PBI’s or remove part of the PBI 3. Request a sprint reset. Set a new sprint with a more achievable goal. Everyone on the team needs to be aware of the cost of each of these options for the production cycle, both money and time­wise so that the best option can be chosen. If the sprint is reset all the unfinished PBI’s are returned to the backlog and the team returns to sprint planning. Stories Stories are a template for expressing the value of a feature/item to the end user. Team
  14. 14. completes one or sometimes more stories per sprint. Usually the stories are formulated in this manner: As a <user role>, I want <goal> [so that <reason>]. ● ● ● User role ­ a player of the game or a user of the pipeline who benefits from this story Goal ­ the clear goal of the story. This is a feature or function in the game or pipeline. Reason ­ benefit to the player when this feature is used in the game. Spikes Spikes are important for video game development. They are timeboxed stories that address areas of great uncertainty and their goal is to create knowledge that help the product owner
  15. 15. evaluate the cost of other stories. Example: “As a product owner I want to see a mock­up video/animation of how our fighting mechanic would look on an iPhone” Stories are sized appropriately to fit into a sprint, if they are too big they’re disaggregated into smaller ones, or if too small can be combined into a larger story to manage more easily by the team in a sprint. From these sprints a list of tasks can be created so the production can be clearly tracked over time. Task list (Boards in Trello) What happens to the design document? Stories collected on a product backlog are intended to replace much of the design documentation. Best practice is to still maintain a technical design document that lists technical risks and strategies for overcoming those risks, but  use it to help prioritize the backlog, which is where all work done by the team originates. Product backlog Prioritizing
  16. 16. ● Value ­ the value that the story has for the player is the primary criteria in determining the priority of that story on the product backlog. By focusing the team’s effort on adding highest value every sprint, the product owner is generating the best possible ROI. ● Cost ­ is the key factor is product owner’s ROI calculation. Some highly desirable features might cost too much to implement. Two equally  valuable features are often prioritized by cost, so the lower­cost feature is given a higher priority. ● Risk ­ implies uncertainty about value and cost. stories with higher risk are placed higher on the product backlog to refine a product owner’s understanding of value and cost of a feature. ● Knowledge ­ sometimes the product owner doesn’t know the value, risk or cost of a feature. So they might introduce a timeboxed story (spike) for a prototype limiting how much time team spends working on it to gain more knowledge on the item. Scrum team(s) Scrum creates conditions that enable teams to achieve greatness through its practices and principles. ● Cross­discipline teams ­ enables teams to deliver features and mechanics that represent clear value for the user ● Self­management ­ enables teams to select the amount of work they can commit to
  17. 17. every sprint and complete it through whatever means necessary ● Self­organization ­ enables team to have a degree of authority and responsibility to select their membership role ● True leadership ­ provide leadership focused on mentoring and facilitation to free the best performance possible from the team by finding the approach between micro­managing teams and throwing them in over their head. Both of these extremes will lead to failure. Cost of change Changes made late in the project can result in costs that are a magnitude or more greater than if those changes were made early in the project. Too much architecture upfront ● It slows the introduction of new features upfront ● Architectures designed upfront often need to be changed later ● Changing bigger systems is more costly than changing smaller ones Role of documentation A goal of a design document is to share the vision about the game with the team. Relying solely on a document to share a vision is full of weaknesses: ● Documents aren’t the best form of communication ­ much of the information between an author and reader is lost.
  18. 18. ● Vision changes over time ­ documents are poor databases of change. Don’t expect team members to revisit the design documentation to find modifications. Daily conversation, meaningful sprint and release planning and reviews are all places to share vision.

×