The Awfully Specific Story of Game X

If I wanted to explain a development process, I could write a boring description. I could name the principles of the process in general terms without any examples and let you imagine what that means in the real world. I could point you to tutorials for different tools and let you guess how these tools are used inside the process. But I won't do that to you. Instead, let me tell you an awfully specific story about Game X...

Game X is a fictitious video game project from a fictitious company, invented to illustrate how an arbitrary development process works based on Scrum (an Agile development process). And you're in it. You're one of the Game X developers, namely a programmer (but this story illustrates the process for everyone in the team). Let me introduce you to your colleagues. Albert is the Product Owner. So he speaks on behalf of our customers (the Stakeholders) which are the gaming community. Bernadette is our Manager. The Development team is made of 5 people: You, obviously. Caroline and Charles are Programmers. Daniel is a Game Artist. We're short one tester but we'll hire him shortly. Elizabeth is our Scrum Master.

Preparation before Sprint 1

Albert decides that Game X would be the best product to meet the market's current needs. He contacts Bernadette, asking that a team be formed. Bernadette chooses a number of available people to work on the project. Unfortunately, we're short one tester. So while the project starts, she hires a new employee, Frank, a QA specialist.

The first meeting is just to introduce everyone. Albert already did all the work of gathering the requirements. He even conducted polls and interviews with actual gamers. Two weeks ago he borrowed Daniel to come up with a Storyboard and sketches.

After the meeting, a few ideas are floated inside the Development team. An overall architecture and specific tools are mentioned. Albert doesn't understand why the architecture should be done that way. Elizabeth says "You have to trust that the team knows what they're doing." More sketches are drawn. A few candidates for the background music are selected. The Development team asks for new software for 3D special effects, which is granted immediately. Everyone is excited about this new game.

Agile Manifesto principle: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile Manifesto principle: The best architectures, requirements, and designs emerge from self-organizing teams.

Elizabeth then plans a second meeting in which the User Stories will be written. Each User Story represents a specific feature to be implemented. The User Stories are categorized under a few Epics. The Epics they identify are: Installer, Levels, Gameplay, Weapons, Characters, In-App Purchases, and Achievements. Take the Installer Epic for example. All it says its:

As a gamer, I want to be able to install the game so I can easily play it.

This short description helps to understand the audience, the need, and the rationale behind it.

After coming up with these Epics, the team helps to fill the User Stories inside. For example, here's a User Story under the Gameplay Epic. The name of this User Story is "Jumping". The description is

As a gamer, I want my player to be able to jump so that I can pass over obstacles.

Note that this User Story includes all the tasks that will be needed to achieve this, including drawing the animation, adding sound effects, writing the code, writing unit tests, manual testing, and the demo of this feature. The team identifies many more User Stories and adds them to the Backlog. This was a long meeting but extremely productive. The GitHub Project board looks amazing. Many of the User Stories contain some supporting material such as storyboards and sketches. Many comments are included to explain certain aspects. Once the Backlog is sufficiently furnished, the meeting is adjourned.

Albert is pretty happy about the Backlog. He re-reads all the User Stories and puts them in a specific order in which he wants them implemented. For example, the most important for him is the Gameplay so he puts a number of those User Stories at the top. The least important is the Achievements-related User Stories, so those go to the end. Albert doesn't have control of the way the project will be implemented but he can control what is going to be worked on first.

This is Frank's first day at work. He's got his email set up and he downloaded all the software he needs as listed on the Intranet documentation. He needs your help to set up his Git client. So you ask him to configure Git and generate an SSH key. So he runs, from his Git Bash terminal, the commands (after the # symbol):

# git config --global user.name "Your Name"

# git config --global user.email yourname@company.com

# ssh-keygen -o

Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/Frank/.ssh/id_rsa): company_id_rsa
Enter passphrase (empty for no passphrase): Password
Enter same passphrase again: Password
Your identification has been saved in company_id_rsa.
Your public key has been saved in company_id_rsa.pub.

# eval `ssh-agent.exe`
Agent pid 20216



# cat ~/.ssh/company_id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== Frank@computer        

You then show him how to upload this key by copying the content of the .pub file and pasting it into a new key in https://github.com/settings/keys

Frank can't wait to clone the repository but you first have to actually create it, including a template of a project. The first thing you do is to go to https://github.com/settings/organizations, select your organization, click on "Repositories" and then you select the "New Repository" button (upper right). You name the project "GameX" and choose all the options required. Finally, click on "Create repository".

On the Code page of this repository, you can click on the button "<> Code" and copy the URL. Then on your computer run Git Bash and navigate to the place where you want your project to reside. Next, clone the repository:

cd Documents
git clone git@github.com:MyCompany/GameX.git        

Now it's time to add the code into the repository. So you create a 3D project using Unity in the folder Documents\GameX, including your code, and import a few useful libraries. You write a sensible ".gitignore" file. You then open the folder in Visual Studio Code and open the GameX folder. You click on the "Source Control" button. Everything that can be done on the command line can also be done in this GUI and vice-versa. For simplicity, I will only show you the commands from now on.

You add your files to the repository and push them:

git add .
git commit -m "Initial push"
git push        

Congratulations, the Git repository is ready!

You send an email to the team and tell them to clone the repository as well.

In the meantime, Frank approaches Elizabeth with his questions about the process because this is new to him. Elizabeth trains Frank on the process.

Sprint 1

Elizabeth then calls the Sprint Planning meeting. Albert asks: "Should I attend all these daily Stand-Up meetings you've invited me to? Would I not be the 5th wheel of the wagon during those?" She answers: "These meetings are meant to be short, just 15 minutes or less. It's important that the team implements what needs to be implemented and not something else. You should be there to give your feedback every step of the way. It would be even better if we'd have actual customers present too but you're there to represent their interests. Besides, don't you want to know how things are progressing?"

Agile Manifesto principle: Business people and developers must work together daily throughout the project.

In this meeting, the team looks at the Backlog and decides how many User Stories will fit into the 2 weeks of the Sprint. But first, it's important to "size" the User Stories in order to get a general idea of how "big" they are. (Two User Stories that take 1 week each to implement takes the same amount of work as ten User Stories that take 1 day each.) The team thus sizes a dozen or so User Stories at the top of the Backlog. They feel like they can implement 8 User Stories within the first Spring. Except for Charles: "We can't possibly be done with all that in two weeks. The AI element alone takes a long time to do." Elizabeth agrees with him: "It's best to underpromise and over-deliver." She suggests taking only 6 User Stories in this Sprint, and if by luck the team is done with them before the end of the Sprint, they can just add a new User Story. And just like that the Sprint Planning is done. Let's be frank: that was painful. But always takes more time on the first Sprint.

The first User Story you decided to tackle in this Sprint is called "Cinematic Scene: Level 1 Intro" and the description

As a gamer, I want to see the introduction cinematic scene for the first level in order to understand the storyline of the game.

The Epic is “Levels”. The ID for this is "L-007". The description says "Draft animation only; Excludes the voice-acting" because this is going to be added at a later time. You work in collaboration with Daniel on this User Story. He says he's sending you a placeholder animation right away and while you do the programming he'll do a draft of the animation (without the mouth movements) and he will take care of adding it to the repository once it's ready. The first thing you do is to create a new feature branch so that both of you can work on the same code.

git checkout -b L-007_level_1_intro
        

This creates the branch locally. You then add the placeholder animation to the Unity project. Then you submit it. You can do that either in Visual Studio Code in the Source Control tab, or via the terminal:

git add 3danimations/level1intro.blend 3danimations/textures/*
git commit -m "Added the placeholder cinematic animation for the level 1 intro."

git push origin L-007_level_1_intro
        

At this point, the branch is also created on the remote repository.

You now can work on the programming aspect. At the same time, you write unit tests for your code. Once it's all ready, you push the code as explained previously. You test your code and make sure everything is working well. You push your code once in a while.

Sometimes there are changes on the master branch. So periodically you merge the changes from the master branch to the feature branch by running the command

git merge master
        

which gets the latest and greatest code from the master branch. (Make sure you do that at least at the very end, just before sending your code to the master branch. And don't forget to test too.) Sometimes you can get a merge conflict. It's important to fix the conflict (if it's a text file, look for the symbols <<<< ===== >>>> which indicate the conflicting blocks). After that, you test the User Story. And then add the conflicted files, which will mark the conflict as resolved.

In the meantime, Daniel has a first draft of the real animation. He already has the project cloned but it's currently in the master branch. He needs to switch to the feature branch for this User Story. He runs the commands:

git fetch

git checkout L-007_level_1_intro
        

He then copies his files on top of the placeholder and runs this to add and submit them:

git add 3danimations/level1intro.blend 3danimations/textures/*
git commit -m "Added a draft of the cinematic animation for the level 1 intro."

git push origin L-007_level_1_intro
        

You get his new animation by running:

git pull origin L-007_level_1_intro
        

This command fetches and merges his changes into your local branch. Daniel and you run one more test as a "review" of Daniel's work. Everything seems in order.

You then tell Caroline "can you please look at my branch and review my code?" She checks out your branch and runs the code. She makes suggestions for improving your code. You implement the suggestion and push the result. She pulls the fixed code and finishes her review. "This is good, mark the User Story as Reviewed."

At this point it is acceptable to merge the code from your feature branch into the master branch:

git checkout master

git merge L-007_level_1_intro
        

Next, test the User Story again which includes the latest changes from everyone. If all goes well, you can now push the merged code:

git push origin master
        

Now that the code is in the master branch, the Continuous Integration system starts to build the code and run unit tests automatically. You make sure you didn't break the build. If you did, you don't want to fix this issue on the master branch. You go back to the feature branch and merge the master back to it. You reproduce the issue. You fix the issue, test, push, and then you go back to the master branch to merge your fix into it.

After the build is successful, you approach Frank and ask him to test the User Story. Frank installs the game and tries it out. He does his best to break the game. He finds that the game crashes when you press Escape during the animation. Good job, Frank! At this point there are two choices; either fix it right away in the feature branch and go through the whole review-merging-testing steps again or write a Bug story on GitHub Project board for later. This bug story would get prioritized and assigned to a future Sprint. After deliberation, you decide it's best to add a Bug and fix this later. Frank will create the board item for that. He then marks the User Story L-007 as "Tested".

Today at the Stand-Up meeting, you briefly give your status as follows:

1. (What did I work on yesterday?) "I just finished the implementation of the Level 1 Intro story, which is reviewed and tested. Thanks, Caroline and Frank for your help...
2. (What am I working on today?) I'll pick up a new story from the board, probably L-011...
3. (What issues are blocking me?) I'm not blocked on anything."

Then to save time you say "That's all for me, now Frank it's your turn." Albert has a question for you but Elizabeth says "Any questions that might take a long time or not pertaining to the whole group should be postponed to after the meeting." (AKA the "parking lot".)

Frank conveys his concern that the animation is just a draft and his fear that this will fall through the cracks. Elizabeth says "You are absolutely right. We need to keep track of those kinds of things. I will add an item on the board to remind us that the voice-acting must be commissioned for this."

You then go to the Sprint board for the next User Story. Near the end of the Sprint, you've completed two User Stories. You decide it's best not to start working on a third one because you might run out of time. And you must have a ready-to-demo product for the Sprint Review meeting tomorrow. So instead you decide to help others with their code reviews and tests. You select a specific build for the game to demo at the meeting tomorrow morning.

At the Stand-Up meeting, Frank has an objection: "This is just the first Sprint and there is very little to show for it. Why go through all the trouble of demoing?" Elizabeth explains: "It's important to always have a recent version that is stable and that we might show to customers, investors, and product managers. Let's make that into a habit. Also, Albert should be kept up to date with what we've been doing."

Agile Manifesto principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Pillars of Empirical Process Control: Transparency

Scrum Value: Openness

The next day, you go to the Sprint Review meeting, in which you show off the User Stories you've worked on. Albert seems satisfied.

Then there's the Retrospective meeting. During the meeting, Charles raises a concern that there are 3 programmers and only 1 game artist and 1 tester. "This is fine right now but soon there will be too much work for them." Elizabeth takes note of this and promises to discuss this with Bernadette. Hiring one more game artist and one more tester would bring the size of the Development team to 7 which is still an appropriate number. More than 8 people would be stretching it.

After the meeting, the User Stories you've worked on are marked as "Done". You then delete the feature branch locally and remotely as follows:

git checkout master
git branch -d L-007_level_1_intro

git push origin --delete L-007_level_1_intro
        

The first sprint is officially over.

Sprint 2

The very next workday, it's time for a Sprint Planning meeting. The Backlog grew quite a bit because now there are bugs in it. Albert has prioritized the next batch of User Stories. Elizabeth strongly suggests that any Bugs should put at the top of the list if possible. Albert agrees. Next comes the sizing exercise. Frank complains: "There are too many User Stories. It will take way too long to size all of them now." Elizabeth answers "We don't have to size all of them at once. We could just do enough so we'll know which ones at the top of the Backlog will fit into the next couple of Sprints."

One of the User Stories is "Add AI to characters". It is estimated that this is a huge User Story that will take weeks to complete. Elizabeth suggests that we split the User Story into several smaller ones. "Maybe a separate User Story for each of the 12 enemy types?" But you have a better idea: "I think we could split it this way: One User Story for the idling behaviour, one for attacking, and one for dodging. So I say we split it into 3."

Agile Manifesto principle: Simplicity--the art of maximizing the amount of work not done--is essential.

In this Sprint, a number of smaller User Stories are selected so the plan is to implement 9 of them. You tackle the bug about pressing Escape during the animation. That gets fixed pretty quickly.

On the very next Stand-Up meeting, Bernadette confirms that a new tester, Ginette, will be transferred over from another project to help us. This will happen at the end of Sprint 2. But we don't have a Game Artist available so we will have to hire one.

Over the next several days, you complete all your User Stories. You overhear a conversation. It seems like Charles is being recalled back into his previous project temporarily because of a bug which he knows how to fix. You suggest: "I'm almost done with my work. Maybe I can take over Charles' User Stories which would free him up for fixing this bug." Elizabeth gets involved in the conversation. "In theory, once you commit to a Sprint, you have to continue working on it for the full 2 weeks. No reassignments in the middle of a Sprint. Changing contexts is a waste of time. I want you fully committed to the Sprint. I will speak to Bernadette and the manager of the other project to shield this team from external distractions."

Scrum Value: Commitment.

So instead of working on Charles' User Stories, you go to the Backlog and pick up the topmost item. But this item requires graphics that are not yet ready. So you decide to pick the second item in the list: AI for attacking.

It's the second week of the Scrum and you are terribly busy. You ask if we could send emails instead of attending the Stand-Up meeting this week. Elizabeth has doubt: "If you're busy you can send an email but I really think it's best to meet in person or over Discord and have discussions." So you decide to take the time to attend the meetings.

Agile Manifesto principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.*

We're now near the end of Sprint 2. But Albert wants you to put the AI work aside and start working on a new feature instead. "Change of plans. In the beginning, we decided to only have a campaign mode for the game but the market right now is all about multiplayer games. So I need to plan and implement a multiplayer mode ASAP." Elizabeth intervenes: "Albert, any change in the scope must be done at the end of the Sprint. We are agile, true, but we also want some stability. For today, add the User Stories to the Backlog and at the end of the Sprint we will bump them to the top of the list." So you keep going with the AI attack User Story.

Scrum Value: Focus.

It's now the end of Sprint 2. All the promised User Stories have been implemented except three. Two have not been started yet. And for the last one, there's a nasty bug in it which makes the game unusable. There are two alternatives: Either we extend the Sprint another 2 weeks, or we drop these User Stories for this Sprint. "If it's not finished, it should be moved to the next Sprint," says Elizabeth, "so let's not demo that one." The feature branch is not merged into the master branch. This buggy User Story is not even mentioned in the Sprint Review meeting.

Albert is not disappointed in the demo. "I'm glad to see good progress this Sprint. Watching this, I'm confident that this game is what the customers will want."

Agile Manifesto principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Pillars of Empirical Process Control: Inspection

During the Retrospective, someone mentions that the User Stories are not sized properly. Some of them are bigger than expected, which is why a couple of things could not be completed. Elizabeth proposes that for the next Sprint we split up large User Stories because smaller ones are easier to size.

Agile Manifesto principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Sprint 3

During the Sprint Planning meeting, Charles announces that he will not be available after tomorrow until the second half of the Sprint. So his utilization is going to be 50%. Ginette joins the Development team. Since she needs to ramp up on the project, her utilization is 70%.

And Albert conveys his desire to have a multiplayer mode in the game. This change is welcomed wholeheartedly.

Agile Manifesto principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Pillars of Empirical Process Control: Adaptation

A number of User Stories are added for this new feature and placed near the top of the Backlog. Then some of the larger User Stories are split into smaller ones and then resized.

A small number of User Stories are selected for this Sprint. And Sprint 3 starts.

The next day, during the Stand-Up, Ginette says she's blocked because she cannot install the game on her computer. You propose to help her in the afternoon. You discover that her laptop is a MacBook and the game was never built for MacOS. But only Charles knows how to fix that. You ask him to make the necessary changes in the build system. It's good that you have this meeting every single day otherwise Ginette would have been blocked until Charles comes back from his other assignment.

You notice that the input system design is not good enough for what the game requires you to do. So you suggest switching to an alternate input system design. "Won't that break things?" asks Bernadette. You explain that, since we have unit tests and system tests, if anything is broken we will notice right away and fix it. It's better to do things correctly than to keep going with this poor design (which could mess things up later). Since you're already working on a User Story related to the input system, then you resize this User Story and fix the issue at the same time.

Agile Manifesto principle: Continuous attention to technical excellence and good design enhances agility.

Scrum Value: Courage

The team has very little to show for in this Sprint which was mostly bug fixing. The multiplayer mode is not ready to demo as it is only 25% done. Is it even worth making a build? Elizabeth suggests: "Even if we don't visually see any progress, at least the fact that we issue a build that is not very buggy is a sign of momentum." In other words, the demo during the Sprint Review may be very short but that build number increased so that's something.

Agile Manifesto principle: Working software is the primary measure of progress.

During the Sprint Review, Albert says "Although there wasn't anything major to see in the demo, at least I can see on the Burndown chart that you're tearing through those bugs and that the multiplayer mode is on schedule. Keep it up!"

At the Retrospective, Charles complains that Frank is not working fast enough. Elizabeth defends him: "I trust that Frank is doing what he can, considering we still have not found a second tester. Charles, I ask that you keep the discussion constructive otherwise it's perceived as disrespectful."

Scrum Value: Respect

Today

It's been 6 weeks since the project started and the team is making steady progress. At this point, we calculate our velocity and see that, at this rate, we will have a working beta in another 6 weeks. That's when beta testers should receive a build if all goes well. Albert really appreciates the fact that even with the scope changes and the unplanned refactorings, we can still figure out a way to schedule things.

Game X is still being developed as of today so there isn't any ending to this story. Anyway, this process is iterative and ongoing and it will only end when Game X is no longer being worked on, years from today. Hopefully, you got a good idea of how our process works.

* Due to the COVID-19 Pandemic, an online meeting with a webcam would be best.