Don’t Lose Sight: The Benefits and Challenges of Changing Task Tracking Systems Mid-Development
As a video game producer, one of your top priorities is to ensure the implementation and protection of a game’s collar pillars and unmovable deliverables. A standard and effective way to accomplish this is through creating, cleaning, and maintaining a thorough product backlog with carefully delineated tasks and conditions of satisfaction. On my most recent project, Asurya’s Embers, we accomplished this with an Agile-like backlog of Epics, User Stories, and Subtasks broken into sprints on Jira. And for much of the project, that system worked well. The leads and co-producers could keep a careful eye on what was or wasn’t being addressed and scrum masters had a list of desired deliverables on hand.
As we progressed through development, however, tasks became more ad hoc and reactive to feedback and bug reports. We would add these tasks to Jira, but coordination sometimes fell through the cracks. Two or three tasks for the same general issue were written under different stories and slight language differences resulted in conflicting deliverables. Around the time we hit Alpha, we knew it was time for a change.
As a producer, I knew we had to achieve high-level visibility without sacrificing depth of detail.
The first order of business was creating a structure for logging bugs in a place for leads to validate and assign to the team. We already had confidence in the team’s experience with Jira. So we created a new Kanban board with a set workflow that enabled consistent reporting. We also established and enforced set criteria for determining which bugs were considered critical, highest, medium, etc. While there were some hiccups in getting the team to use the Kanban board as intended, the learning curve was supported by our enthusiastic leads who ensured and eased the process. Though the Jira workflow may have been more complicated than circumstances demanded, it accomplished what we wanted. The experience also gave me a better understanding of how to adapt to others’ styles. Through it all, we continued to keep the Product Backlog active until all the initial tasks were determined closed or “OBE” (“Obsolete by Event”) at the end of Beta.
While the landing zone for found bugs and play tester feedback was useful for the developers, it still painted a messy picture. Yes, we had a system for ranking the bugs from low to critical, but as a collective, they did not capture the team velocity trends the way our backlog had. Our Stakeholders did not need to see the hundreds of detailed bugs we were finding nor which developers were assigned to them. That’s why we decided to create a separate “Key Priorities” Kanban board that captured the high-level deliverables necessary for reaching our goals.
I ultimately decided to put this second Kanban on Monday (a different project management software) for three reasons. The first was to better differentiate the high visibility board from the other two in circulation. We were already using Jira for the product backlog and bug tracking and a third Jira board or project may have confused the team. Multiple projects and boards under the same software is not necessarily a bad thing (and can certainly be efficient) — it’s valuable, however, to recognize how and when a different program can help differentiate the goals and purposes of each board.
The second reason for choosing Monday was that its bright colors and bold fonts made the board easy to read and grasp. Color-coded priorities, statuses, and disciplines allowed for a rapid, surface-level understanding of the project’s status. I broadcast Monday on two large screens in our studio rooms so that the progress was universally displayed to the team. Just because the Monday board was used for high-level storytelling does not mean it lacked detail. The leads team used the “updates” section on tracked items to link issues to more detailed Jira tickets (if applicable) and write the ongoing blockers, due dates, and other relevant info that came up during our daily scrums.
The third and final reason for choosing Monday was that I had used the software for a similar purpose with my stakeholders on a previous project. He and I had an established cadence of deliverables and expectations and how to present that information. The stakeholder could ask for a meeting and within minutes, my co-producer and I could easily showcase “These are the top issues today, these are the top this week, and this is how they’re being addressed.” When you have a proven history of “I can get the job done with this tool, " that tool should remain an important piece of your arsenal.
If you change systems mid-development, the key is finding solutions that work for your team and give confidence to your stakeholders.
What’s important to remember is that first and foremost these systems are for your team. It can be frustrating to spend hours on a well-crafted solution nobody uses. As a producer, you should regularly check in with your developers and ask them if they find anything confusing, excessive, or overwhelming — so be ready to adapt. You may prefer Jira or Monday, but your team and managers may have a better history with Trello or Asana. If and when you make changes, be it at the start, middle, or end of a project, try a soft rollout. See if the developers can handle and make the most of it. If you do implement a secondary system that is meant more for the stakeholders’ eyes than the team’s, be clear with everyone what the purpose of that system is and ensure there is no confusion between the two. When using multiple software suites, complementary information and presentation are always the goal. When this is done right, you will reach the end of the project with limited surprises and confidence in the product you’ve delivered.
Asurya’s Embers is a bow and arrow first-person shooter with a unique light and shadow mechanic coming soon to Steam and Epic Game Store.
