A Cog in the Cosmic Machine
A narrative based resource management game for Bradley University's 2021 Capstone project.
When: August 2020 - Present
Team Size: 22 people
• implemented JIRA & SCRUM into team
• Held team / lead meetings 4x a week
• Decided upon team leads, functional teams, and discipline teams
• Held sprint retrospective/planning meetings before and after every milestone
• Clarified communication, messaging, and organizational issues from team members and solved them. Removed any and all bottlenecks.
Visual Examples of Production:
Sprint / Schedule Planning
(top left image) For each semester our professors gave us basic deadlines for when milestones are due and when in class playtesting will be done
(Top right image) Based on the information in the aforementioned schedule I created a sprint schedule for each milestone. Each was designed to maximize time given for each submission and playtesting date. Break days and planning dates were also decided upon to attempt to mitigate burnout as much as possible.
(Bottom right image) I wanted to learn Hansoft as many companies I'd like to work at (such as Volition, EA, Capcom, etc.) use it so I created the next five months worth of sprints in the program. I did this for no other reason than I wanted to learn more about the program.
On the left are some of the burndown charts pulled from my team's JIRA board.
On the Y axis is storypoints. A storypoint is a numerical variable in JIRA that can be assigned to any task. The higher the task the longer it will take.
I used the Fibonacci sequence (1, 2, 3, 5, 8, 13) to determine the value for each ticket as the larger the task the less clear it is how long it will take.
For example: 1 = 1 hour | 5 = 1 day | 13 = the whole sprint
Story points are incredibly useful if used properly as data from each past sprint can be taken into account of how much story points a team can handle in any given sprint.
It is clear in each burndown that tickets were either not moved or not completed in a steady pace. All the charts show that there was crunch in every sprint.
What I hope to learn from this is make sure that people are not waiting till the end to either finish their tasks or move their tickets. Keeping closer tabs on progress will be key.
(Top Left / Right images)
Team Meetings (Tue / Thu): These meetings consisted of the whole team and each discipline team did a small stand up about their respective disciplines progress and then I would give announcements. These meetings were short so I didn't keep the team from working for too long.
(Bottom Left / Right images)
Lead Meetings (Wed / Sat): These meeting consisted of me and the lead of each discipline. These meetings tended to be longer and on top of detailed stand ups, higher level decisions would be decided upon such as cutting or changing features and tasks.
I helped each of my discipline leads come up with role sheets to make clear distinctions of who is in charge of what.
On the left are two examples of the sheets. Each has clear explanations of...
1. The general overview of their respective role
2. Specifics to clarify roles that could be confusing during production.
Each sheet had to be read over and approved by every other lead to make sure everyone has agreed to everyone's terms and tasks.
While these sheets aren't something required of us as a team to do, creating them was extremely helpful in the long run. There were plenty of situations which came up during production where there was confusion as to who has the final say. These sheets were able to quickly solve these disputes. Any problems that couldn't be solved through the sheet were decided upon and any decisions made were added to the sheets for future reference.
In order to keep track of what assets and features needed to be created for our game I made spreadsheets for each discipline. On the left are a few examples of the sheets. Each has general info about each asset and each asset needed to be approved by relevant leads in order to work on them.
Asset lists were easily one of the most important pieces of data in my teams whole production process. These lists made sure that everyone who needed to know about what was being created not only saw what was going to be worked on but approved it too. This helped keep everyone accountable and on the same page with priorities and goals. This list also kept everyone updated on the progress of each asset too. While progress was primarily tacked through JIRA these lists were a great way to quickly see the state of assets specifically.
the goal of this video was to inspire my team and allow everyone to reflect on how much progress had been made in the first semester of our project. As a producer I know that it is my job to make sure the as many of the people on the team are not only working their best but feeling their best when it comes to their work and I thought no better way to do this than show all the progress made in chronological order.
This video not only made some of my teammates clap and cheer but cry as well in realizing how far as a team we have come. I showed this the day after our final submission and while many other teams might have felt extreme burn out I had gotten many comments on how this video motivated and excited many to work even more next semester!