Dev Log 5: Scheduling My Work
Introduction
Scheduling is important and it sets up the foundation for your whole workplan and methodology moving forward. Even as early as pre-production, you need to understand when your roles and responsibilities need to be fulfilled and at the highest priority. It's important to understand your capabilities with an estimate on time. When my team and I assign ourselves work to do each week, it's with an understanding of the time we have available to handle the task.
Universal Requirements for Scheduling
Who ever is working on the project, solo or in a team, needs to have a good understanding of time restrictions. You should always establish dedicated timeslots in your week to get things started. This is a simple step, but it's one of the most important for designers to adhere to. If timeslots are compromised in any way, they begin to lose their power. This power is what fuels the whole work process. When working in a team, it is ideal to have everyone working at the same time together. Even if everyone has their nose in their work during this period, everyone will benefit from being able to make quick decisions or deliver quick answers right there together.
A Breakdown Structure is important for establishing what it is that needs to be accomplished, what this task is composed of, and then what needs to be done to complete each portion. Once you are in the post-production face of your project where you completely understand what it is you are trying to make, you should establish a Product Breakdown Structure, or a PBS. The PBS is an essential step in scheduling your work moving forward once you've actually established what you're going to be making. A PBS turns the broken down components of your product and lets you lay it out in a straight line to create a roadmap.
The PBS when combined with your weekly timeslot tells you how long it will take you to finish and ship your product.
Additional Components of Scheduling
Regardless of a PBS, you need to be able to prioritize the components to your task list. Prioritization is established by a number of factors that may be different for everyone. A system to help coordinate priority across a team is through the use of Story Points. Story points is a design method that functions modularly. Meaning, you can pretty much assign your own hot-take to it to function in a way that works for you. You essentially assign a number value to a task to define how challenging or important it is to the grand scheme of the product. I use it similarly, but I have added a couple components as well. Here is what I use to define priority for any given task:
- How many tasks rely on this one being done?
- What is the priority of those tasks?
- Does this require other tasks to be done before it can be implemented?
- What is the priority of those tasks?
- Have I completed it efficiently before?
- Can I reproduce it effectively?
- Can I reuse my work effectively?
- Does this involve skills that I, or my Team, aren't proficient in?
- How long will it take to learn?
- Can I find someone to handle it?
- How long will completion of this task take?
- How essential is this to the core design?
- How essential is this to the core experience?
- Is this a requirement of the project?
It's quite a bit to consider for each small task, but it's vital in understanding the work required. Being able to establish all of this is an important part of being a designer and being able to push projects to completion. Once the team is in understanding of all of this, they can come together on a value to assign to the task as its story points. The higher it is, the more important it is. A past Professor and professional game designer of mine stated that he uses the Fibonacci sequence (1, 2, 3, 5, 8) as a means to tier story points so they have numbers that can't be contested amongst each other. I like to use prime numbers (2, 3, 5, 7, 11) personally. They have the same effect. The decision making process of your team should contribute to resolving a conflict of opinion over what number each task should be.
Conclusion
Using a combination of design principles and methodology, you can put together a very effective strategy and schedule for handling any kind of project, assignment, or product development. It's important to create a strict schedule and use it to fuel the framework of your workflow. A breakdown of your project should be used to piece together your tasks, then these tasks should be given priority based on its understood importance and challenge, then assigned a Story Point number. This whole process will help you piece together everything you need to complete a task, within whatever timeframe you have set out, without compromise.
Game Practice Dev Logs
A recap and debriefing on game design lessons I've learned in this week.
Status | Prototype |
Category | Other |
Author | MisterSpectre |
Tags | design-practice, development-log, dev-log, game-practice, info, information, journal, solo |
More posts
- Dev Log 11: Post-ProductionApr 04, 2022
- Dev Log 10: Planning and ImplementationMar 21, 2022
- Dev Log 9: Playtesting and Production IIMar 11, 2022
- Dev Log 8: Playtesting and ProductionFeb 15, 2022
- Dev Log 7: Pre-Production PrinciplesJan 30, 2022
- Dev Log 6: Learning Reflection - How will this prepare me for next semester?Nov 26, 2021
- Dev Log 4: User Centered DesignNov 13, 2021
- Dev Log 3: Beat MappingOct 22, 2021
- Dev Log 2: Project ProposalSep 30, 2021
Leave a comment
Log in with itch.io to leave a comment.