Game Production - Scrum

You need a Membership to view this content. Select your Membership from here!

Course Contents
0%
Home














Game Production / Production methodology

Scrum


After this page:
  • You will learn what is SCRUM methodology
  • You will learn how to implement Scrum in game teams
  • You will learn about different elements of Scrum

INTRO

  • Flexible holistic strategy where development team work together to reach the common goal
  • Iterative way of working
  • The word ”scrum” is a rugby term, meaning manner of restarting after minor infraction
  • Scrum is process framework of Agile approach


SCRUM PITFALLS

  • Often only certain elements of scrum are used, but traditional management set up stays in place
  • Daily scrum meetings turn into micro-management reporting
  • Team is not fitted for scrum methodology – things don’t get done, lack of self-responsibility
  • Iterations lose the big picture and become self-serving purpose
  • Story points are misunderstood and estimates are highly unreliable


AGILE METHODOLOGY

  • Agile software development refers to software development methodology based on iterative development, where requirements and solutions evolve through collaboration between team members
  • The Agile movement is looking to alternatives to traditional project management. Agile approaches help teams respond to unpredictability through incremental, iterative work cadences and empirical feedback.
  • Agile methodology is alternative to waterfall, or traditional sequential development


AGILE MANIFESTO



SCRUM IN THE NUTSHELL

  • A product owner creates a prioritized game “wish list” called a product backlog. Backlog can contain features, new content, fixes, technical upgrades, new designs etc.
  • During sprint planning, the team pulls a small chunk from the top of that wish list to a sprint backlog and decides how to implement those pieces.
  • The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal and makes sure scrum methodology is properly implemented
  • At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
  • The sprint ends with a sprint review (results showcase) and retrospective ( the whole team discuss what went well and what went wrong and takes learnings into new cycle)
  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again


ROLES AND RESPONSIBILITIES


ROLES IN MORE DETAIL

  • Scrum Master: The Protector
  • The ScrumMaster is the protector of the team, making sure that everyone on the project can focus on their work. Potential distractions may be directly associated with the work -- the product owner who oversteps the boundaries, for example, and starts to dictate the work approach. Or the ScrumMaster may need to protect the team from organizational disruptions or internal distractions. The second element of the ScrumMaster role is to protect the Scrum process itself. The ScrumMaster is the expert on how Scrum works and how it should be applied. She will ensure that the product owner and development team stay within the Scrum framework.

  • Product Owner
  • The product owner is the cornerstone of project success, responsible for defining the work that needs to be completed and prioritizing that work. She needs to know what the project is expected to deliver -- to the players and to the organization. The product owner must also be the face of all of those interests to the project team, acting as an expert guide as the team carries out the project. The product owner fully understands the business value; her entire focus is on ensuring that the work done aligns with the work that needs to be done to meet the product objectives. This may create the temptation for product owners to try to control the work, but that is not part of their role

  • The development team: autonomous collective
  • A typical Scrum team consists of five to nine people and generally includes the functional roles required to complete the project. Titles are only relevant in establishing each individual's expertise. The team acts collectively to determine how to achieve their goals. The specific features they work on are determined by the priority established by the product owner. The way they work is guided by the Scrum process. Everything else is up to the team to manage


SCRUM PRINCIPLES


SCRUM VS WATERFALL


In waterfall model, most pressure is at the end of development cycle,
when QA just starts and chances of finding critical issues are high. That
period is also known as “crunch time” or “crunch”.


In agile development, risk is mitigated through iterative development and
as project develops, we have increased trust in it’s reliability.


SCRUM TOOLS

  • They can be digital and/or physical
  • Sprint backlog can be on the white board or post-its, so it’s always visible to the whole team
  • Burndown chart; shows team progress
  • Can be part of the complex software tool or simple version made in excel
  • Purpose of Scrum is to be agile, light and without heavy bureaucracy; tools should make scrum easier, not more complex


BURNDOWN CHART


Burndown chart is a visual representation of how much work is done in a sprint. It’s a great indicator of how the team is going with the tasks and it helps us predict when the work will be finished.


It’s usually presented as a chart, with one axis representing remaining work and other axis time left.


STORY POINTS VS TIME UNITS

  • You need to provide some high-level initial estimates, in order to get an idea of the size of your product backlog items
  • This helps to inform the decision about priorities, will features be worthwhile and how complex they are
  • But as yet, you don’t know much about the items on the backlog. You don’t know what tasks are needed to complete them and you don’t really know how you will implement them
  • You have to do a very high level, top down, indicative estimate (guesstimate)
  • Development teams are more objectively able to give guestimates of ‘size’, without giving an estimate in time that they might be held to.
  • We’re not asking the team “how long will it take?” but instead “how big is it?”
  • How many times have you heard someone say, ‘don’t worry, I won’t hold you to it; I just need a rough idea’? And of course they do hold you to it. Of course they do!


USE OF A POINTS SYSTEM

  • Suggested range is from 1-21
  • Often Fibonacci scale is used
  • To make sure the scale works for you, I suggest you start by picking what you think is the smallest thing on the backlog. Give this a 1. Then find the thing you think is the biggest thing on the backlog. Give this a 21
  • Don’t feel you have to size the entire backlog. Size enough of the items to see you through the foreseeable future. Remember it’s already been put in priority order so make sure you work from the top.
  • Estimate as a team. Another person perspective can help see hidden complexity and co-dependencies.
  • scientifically significant set of numbers, where each number is the sum of the previous two. They are:




NOT COMPLETED

Complete all exercises on a page to complete the page.
Edugametion - Page Completed xxxTITLExxx
Total completion:
0%
You have completed 0 of the 20 pages.
Completed pages give a full star. Full stars are added to the total completion.






Continue


Next : Time management

Please rate this page: Edugametion RatingEdugametion RatingEdugametion RatingEdugametion RatingEdugametion Rating
Report an issue

We use cookies to improve our site features. By using this site you agree to the use of cookies. Privacy Policy.


Chat with us