6 quick tips to effective scoping in game development
I often get asked how we ship games at such a rapid pace at Mighty Bear, and how we decide what to do, and what to focus on at any given point in time. Scoping effectively and together as a team is one of the most important parts of the development process, and can make or break a project. At Mighty Bear we’ve spent the last 5 years refining and tuning our scoping process, and I want to share some important tips that you can hopefully also share with your team, no matter what stage development you might be in.
Constraints and Requirements
It’s important to define early what are the blockers, roadblocks, and barriers your team will face in the journey to shipping your game. What are some of the must-haves, the wants, or the must not-haves? What are some clear parameters that the team must work in? Some projects need to ship before a specific deadline, while others are more open-ended and iterative. Others have a list of features that they must have for a specific platform, and so they must be done and tested before a specific date. Getting your team to understand the confines and boundaries in which development needs to happen helps to get everyone on the same page early on to prevent miscommunication on expectations and targets.
Failing to prepare for failure is failing to prepare
Think about some of the friction points that will prevent you from delivering what you’ve set out to accomplish as a team. It’s easy to align and decide on what you will ship, but it’s more difficult to ascertain what will happen over the course of development. Consider having a “Pre-Mortem” for your project to discover what are some of the ways your project could derail. Get your team and each discipline within it to list down potential scenarios in which the project has failed to deliver or done well, and what are some of the situations which would cause this to happen. Understanding what could kill your project will allow the team to work around those challenges early and take preventive measures.
Plans change, scope should adapt
Every week, the team at Mighty Bear will get together to run a weekly prioritisation session where we collect feedback and improvements from various sources and try to make sense of what the next sprint/milestone will look like. We collect feedback and improvement suggestions from play tests and customer support, and take a look at the planned features and improvements for that milestone. After that, we try to prioritise any new and incoming tasks as best as we can. This could be scaling down an existing feature to make sure we can deliver it before the end of a milestone, or cutting it out completely, if it’s possible to leave out of the milestone. This meeting includes almost all disciplines including product managers, designers, QA, CS, some engineers, and artists. As you can see, most teams should have a representative, but the whole discipline team doesn’t need to attend every prioritisation meeting. Divide and conquer!
It’s important to incorporate as many sources of feedback as possible to get a bird’s eye view of how things are developing across the entire project, and to make sure everyone is aligned on the status of tasks and what the priorities are. Our team has a policy of minimising the number and length of meetings we have in a week, but this is a meeting we usually give particular importance to.
Understanding your team’s velocity
It’s important to keep track of your team’s velocity — most teams already have tools they use like Trello or Jira to keep track of tasks, but it’s important to also take note when tasks are complete. By seeing how close your team gets to completing their estimated tasks, you can improve your estimations over time and build a better model in which you can scope more realistically. 9/10 times, motivated teams will inflate their estimates so it’s good to keep track of past sprints to get a more realistic view.
Stay laser focused on the goal
It’s important for the team to remain laser focused on the goal and not to get side tracked by something that shouldn’t be a priority. As teams get larger, sometimes some tasks can get de-prioritised and cast aside while other non-essential tasks get worked on because they are “easy” or “we should get it out of the way”. It’s important that the team understands the full scope of the sprint/milestone and tackle things in the correct priority and order. Sometimes tasks can have pre-requisites or might be blockers for other tasks further down the chain. Other times, team members might be blocked until a dependent task is completed by a different discipline. It’s good to keep track of dependencies and make sure the team is focused on whats important. Daily standups, catch ups, 1-to-1’s and syncs can all help to align the team.
When is something “done?”
In any creative and iterative endeavour, it can be difficult to determine when something is “complete”. There is always something to improve or tweak, but work cannot continue indefinitely and what being “complete” looks like needs to be defined at the beginning of every milestone. During milestone and sprint planning, it’s important to define success criteria for each task, so that anyone working on the feature or task can clearly see when something is deemed as feature complete. Often, the one reviewing the work (a designer or QA tester) can refer to this checklist of requirements laid out in a success criteria to determine if a feature is done or not.
This list is by no means exhaustive, but I hope it has hopefully served as a good starting point for improving your team’s efficiency and velocity. If there is one thing to take away from all of this — is that while scoping effectively and doing rigorous cuts can help — it is ultimately the team that has to deliver the work. Being realistic with your targets and what you can achieve in a specific amount of time will always lead to better quality work.
