In our previous blog, we discussed the regular events that you could set up to address a number of issues that you might be seeing with your team, usually around communication and visibility.
In this blog, we wanted to deep dive into processes that you can use to refine your day-to-day work on projects. Most of these processes assume that you are already using some kind of task tracking or card system (like Trello, Jira or Kanbanize). If you’re not doing that – here is a resource to discuss the pros and cons of that to help you get started!
Definition of Done
You should use this if you are finding that work that has been ‘completed’ still seems to have other things to do. For example, you find bugs in completed features, there are processes like optimisation that haven’t been completed, or there is confusion about when work is ‘completed’.
Definition of Done is a set of rules that you determine for when a card is completed. Some example rules might be things like:
- All work has been merged back into the main branch
- All assets created have been uploaded to the appropriate place
- All tests have been run on the new feature, and all pass
- New tests have been written for the new feature
Definition of Done rules are agreed upon by the entire team, and should apply to all the cards / features that the team works on.
Card Lifecycle
You should use this if your team is handing work between people, and struggling to have a clear process for when work should be owned by one person over another.
When teams start using task tracking software, there will be a standard set of columns (like To Do, In Progress and Done) which the software prescribes. One of the problems I see with producer-less teams quite often is that they haven’t implemented columns that more closely fit (and define) their work structure. Setting up a proper card lifecycle is great for this.
The goal for a card lifecycle is to ensure that your board represents the various stages that a task can be in, with clear rules on when and how a card enters and leaves each stage. This removes any ambiguity about who is responsible for certain things, as well as what should be done on a card at any given point.
Here’s an example – this is our card lifecycle at time of writing. However, this again is just another default, and you shouldn’t use it exactly as is, but think about the way your team operates, and set up a board to reflect the cycle of a card that you want to promote.
Backlog Refinement
You should use this if you find that your cards are not adequately described for people to work on them. E.g. Does your team often have confusion about what the specifics of a card actually entail? If so— backlog refinement is for you!
Backlog refinement is a process for ensuring that every card is adequately described to be worked on. There are a few general rules of backlog refinement:
- By the time a card is ready to be worked on, it should be described so that any team member (even those who haven’t seen the card before) have a clear understanding of what completing this card looks like.
- Cards that are planned for far in the future shouldn’t be described too much (since by the time the card is to be worked on, the project may have changed, or the desired goals for the card may have changed)
Putting this together, the goal is to use a ‘Just in time’ system for card description. One team member (usually in games, the lead designer) should go through and ensure that cards for the next 1-2 weeks are adequately described.
What this looks like can vary between teams. Some teams have dedicated ‘backlog refinement’ meetings, whereas some teams do backlog refinement as a part of sprint planning, or independently led by the lead designer outside of any specific meeting.
Estimation
You should use this if there is confusion about how long cards will take to complete, or the team is having trouble knowing how much work can be completed in a week.
Estimation involves ensuring that each ‘fully described’ card has a size on it. This size ensures that the team has full visibility over how long things are going to take. Often teams will begin by estimating things in terms of hours or days, but ideally will move to a relative sizing system (like planning poker).
At a high level, relative sizing is useful for a few reasons:
- Humans are bad at accurately estimating numbers, but much better at relatively comparing things (for example, if I asked you how much an apple weighed, you might not give me an accurate answer, but if I asked you whether an apple or pineapple weighed more, you would probably be able to answer easily).
- Tasks are inherently a bit fuzzy, which means that even if we could estimate perfectly, tasks would shift slightly over time, meaning that we would be incorrect anyway. The best we can hope for is a rough categorization.
- It’s not always guaranteed that the same team member will work on a task, and different team members may have different amounts of time to complete the same task.
To solve these issues, many teams use Relative Sizing. This allows you to assign a ‘relative’ number to a card (not a measurement of anything specific, but an abstract amount of Story Points). Then, this can be used to start gathering data on how many story points a team can complete per week, and get a rough idea of what is feasible to complete each week.
For more information on how to use relative sizing, you can see this resource.
Forecasting
You should use this if you are having trouble predicting how much work will be completed over longer timeframes (e.g. months – years).
Once you’ve started doing relative sizing estimations (described above), you can expand this out into longer term forecasting. By looking at the amount of work that a team completes each week (known in Agile as the ‘velocity’), you can start predicting how much work will be completed per week, and from there start forecasting when specific tickets will be completed. If your backlog is fully estimated, and in priority order, you can even start to make predictions about when specific tickets will be completed! It’s an incredibly powerful tool, although it requires you have all your other processes humming along beautifully before it will work accurately.
Version Control & Review Process
You should use this if you are finding that new bugs are frequently being introduced to your code, or there are a lot of merge conflicts or other code quality degradation over time.
Your team should definitely be using version control. If that is a concept that is new to you, here is a resource that explains more about version control and why to use it.
The specific process to discuss here is the merge and review process. When features have finished being developed, it can be very helpful to have a review process that ensures the feature fits its requirements, that there is no code degradation, or that there are no design issues or other impacts.
The general way this process runs is that by following these rules:
- You have a ‘main’ branch, with a goal of being stable with no major issues
- New features are always developed on a separate branch, to ensure that WIP code or potentially broken features don’t cause issues for the main branch
- When a feature is completed, it goes through some kind of review before it is merged into the main branch, to ensure it meets the standards for quality.
The specifics of what that review looks like depends on your project and team composition. As some examples:
If your project requires a high level of code quality, has junior team members who you want to focus on helping grow, or strict standards to be adhered to, you may want a technical review. Code should be reviewed by a more experienced engineer to ensure it adheres to quality expectations before it is merged.
If your project is technically complex and has high potential for bugs that impact multiple areas, you might want a QA review. Features should be reviewed with a focus on testing the feature (or testing other high-impact areas of the game) before they are merged.
If your project has a lot of artistic assets, or a complex design, you might want a design review. Features should be reviewed with a focus on ensuring they adhere to expectations around design before they are merged.
Many version control systems have inbuilt tools for performing merges (commonly called Merge Requests, or Pull Requests). So— look at the tool you’re using for version control, and see what system you can use fairly easily.
We hope you enjoyed reading this! Have a question or want to chat more about game development? Reach out to us!
Other places you can find us:
- Our other game development resources
- Join our Discord server
