3. Terminology A storydescribes a capability that adds value to the product A team plans a sprint using stories as input A sprintis the time period in which the plan is executed A story pointis a relative estimate of effort of a story A taskis work that is done to complete a story
4. Terminology Agile is a lightweight process, to produce a quality product, that accommodates change Scrumis an agile story driven process that delivers value at the of each sprint Leanin game development formalizes the phases of content production in and around scrum Retrospectivean end of sprint activity by the team to determine how well things are going
5. Synonyms Daily Scrum: Stand-Up Story: User Story, Feature Sprint: Iteration (but not the in the waterfall sense) Stack Order: Priority Story Points: Feature Points Retrospective: post-mortem
16. It’s not me, it’s you Agile is not… A silver bullet Guaranteed on-time delivery Culture change Dysfunction junction FUD Endless development Management fad Pass/Fail Meeting Hell
19. Stacking wilds animated symbols 20 symbols 5x5 100 lines I want my game features! buttons top glass meters movies
20. User Story As a <type of user> I want <some goal> so that <some reason>
21. Let me tell you a story... As a player I want games to be fun so that I can win lots of money As a player I want to bet on a game in order to play it As a player I want stacked wilds in a game because visual anticipation is exciting to me As a player I want to view the see pays screen in order to understand the game odds
22. Are you tasking that story? Take a look at the story: As a player I want to bet on a game in order to play it Breakdown: player: user type bet on a game: goal play it: reason
23. Are you tasking that story? Task breakdown - for art Button Symbols Reels & pay lines Meters: bet, credit & win
24. Are you tasking that story? Button 10 bet buttons 1 bet max 1 repeat bet Symbols 10 static 2 animating Is a task for each button appropriate? Was this story written with an appropriate level of detail?
25. What you don’t know Product Owner role will clarify the content of a story will prioritize stories in order of what should be done first will serve as the interface to product management, stakeholders, etc. make decisions keep the team fed and happy - or at least caffeinated
27. Scrum Questions: What did I do yesterday? What am I doing today? Any impediments to progress? The majority of the sprint is dedicated to these questions
28. For my final trick Can I get a witness? Always show your work at the end of the sprint Product owner, stakeholders, team, etc. No, that’s not quite right Expectations change over time Stories/tasks for the next iteration
29. In retrospect That felt good, but next time... Team discusses the Good, the Bad and the Ugly Keep the Good Action plan to improve the Bad The Ugly is usually rolls uphill (and back down again)
33. Game Development Finding fun Expecting a delivery “need it for the show” Stage this Concept Pre-production Production User Alpha, Beta
34. Game Development Release me Releases enable “review early and often” habit You are in debt A release demo combined with sprint retrospective will help free the project of creative debt Certainly lean Lean game development augments scrum with stages Time in a box Timeboxing is a lean technique to facilitate creative work on a time budget (task hours)
38. Team Scrum is not team building You are what you eat Play the release, look and feel right? Four points inward Cross-discipline, self-managing, self-organizing, mentoring Distributed fragmentation Build in Las Vegas, ship from Reno
40. Credits Sound Credit: Mixtikl by Intermorphic Art Credit: 365 Strange Attractors by Joe Chavez
Notes de l'éditeur
Why Agile? That’s why we are gather here…Rhythm – In agile rhythm is everythingGame development – There are a few specifics that apply to agile in a game development contextTeam – a few slides on who does whatAgile planning – a short exercise on planningRubber… meet road – the flavors of agile in our world, the studioNext steps – what happens after these few hours we spend together
Story – is a lighter form of a requirement but stated in a way that everyone can understand. It has a basic syntax or form that focuses on who, what and why.Plan – planning is key to agile but mostly in the short range sense. Long term planning is what feeds the project it’s stories. The project focuses on a plan that delivers value early and often to narrow the “expectation gap”. The expectation gap happens when the stakeholder of a product has expects something that is not what is delivered – closing the gap is key reducing effort what is NOT needed.Sprint – a short range plan that selects the most important stories for delivery in a release.Story point – is a relative estimate of effort to complete a story... Humans are generally bad at absolute estimation exact things but they are pretty good a “relative” estimation.Task – is the work needed to complete a story, there can and usually is more that one task per story. Tasks are usually estimated using hours – absolute estimation by consensus (group thinking). However, it is after all and estimate and if things go south then the estimate is updated to hours remaining.
Agile – visit http://agilemanifesto.org/ for the details… looking at from out perspective it’s a focus on quality and to anticipate change as opposed to react to itScrum – it’s origins are from Rugby… a brief huddle to determine a plan (daily) and allow for adjustments to be madeLean – Agile is a general process. For some areas, like content creation for game development, the stages and tasks are fairly well defined. Lean attempts to marry this with a typical agile engineering process. Retrospective – Helps to improve process and to clean up the funk!
Life wasted or lean machine?Life wasted – ever create a set of art only to find that at some point while you were working the “focus” of the project changed… wasted time.Lean machine – find yourself waiting on another artist, sound guy, engineer for something… too much fat.
Time for a 5 minute musical interlude…
A few examples… some with value, some not so much.The first one: a story we can implement? Not reallyThe second one: some basic functionality that every game should have, maybe too generalThe third one: a specific game feature, getting closerThe forth one: about the same level as the previous, closer againThe point here is that stories are like requirements – if they are vague, non-specific and wide open to interpretation the end product will be too.Good stories are a key driver to a successful project – regardless of the process.
Let’s break the second story down to take a closer look at the syntax of a story.
Okay, now a quick run at a task breakdown for the story. Can these be hour estimated? I think so but the quality of the estimate will more than likely be too vague.
Drill down to another level… say buttons and symbols.Now we have a quantity of buttons and symbols… better task hour estimates are probably found here.A quick survey:How long does it take to create content for a dynamic button?Static:With animation:How long does it take to create a symbol?Static:With animation:In this case since we, as a group, have made slot games before the jump from the story to the tasking was easier. I would almost say that this can apply to any game with buttons and symbols. So imagine, getting lean on this part of the game content creation process and having more time to work on new content that will set the game apart from others.
So, what happens when a story is too vague – turn to the product owner for guidance.
My Uncle Bob Martin always says, “Planning is a good thing, taken in moderation.” Getting into the agile rhythm is where the plans are executed.
Everyone on the team does this in less than 15 minutes. Do the math, 7 person team minus 1 minute for overhead and that’s 2 minutes per person.Key to this:Summarize yesterday – I finished x,y,zTask for today – I’m working on x,yBriefly state the blocking condition – communicate the details later on (or before and have a plan ready)Do this to avoid rat holes and keep the meeting short.Oh, and show up on time. Those who are late need to put a $1 in the tip jar.Do this everyday for the life of the sprint…There is a bit of accounting that has to happen before or right after the meeting so the project manager and product owner can measure progress… more on that later.
What happens at the end of the sprint?A demo – to the team, product owner and interested stakeholdersHere is where the anyone has input with regard to the quality of the content in the demo. Pass acceptance tests?Visually appealing?Fun to play?Sounds good?So, does a demo sound like too much effort for an every few weeks event? At first blush the answer may be yes. However, take this situation into consideration: A stakeholder (VP, product manager, etc.) gets wind of this great new game the studio is working on and wants a demo. In the current environment a mad scramble ensues, assets need to be located, the engineer has to build the game and put on hardware, meetings are scheduled, etc. Sounds like a fairly large disruption to me. Even bigger if source control and CI are not being used by the team. A better answer is: okay we have a demo scheduled on Friday (end of sprint) come on by OR have the last demo up and running and send out and open invitation. The team keeps working and the show and tell is a minor bump in the sprint.