A year ago I posted a question on BlueSky. I was curious if anyone had a good experience working on a solo game development project using Agile.
I’m not really convinced that Agile is the right way to go to begin with, but it’s how I originally structured the project on Azure DevOps and at this point it would be difficult and time consuming to change it to something else. Since I have limited time to work on my project between full time employment and household chores, I found that trying to choose a couple tasks to get done in a two-week sprint wasn’t realistic. Some things worked, sure, but when it came to more nebulous tasks like “Make this entire dungeon map.” it just wasn’t possible. I tried breaking the bigger tasks down into smaller tasks like Agile expects, but I quickly found that I was spending more time trying to plan the work than actually working. That’s an alright place to be when you have a planning team at a large company, but when it’s just you doing everything. Without a solution in front of me, I reached out on BlueSky, but I didn’t get any answers. After refining my approach over the last year, I think I have a solution that answers my need.
Instead of “Sprint 123,” I name my sprints after the version that I’m working on. The screenshot above is for “Version 0.4.2” in my beta development. I set the start date on the sprint to one day after the previous sprint ends and the end date is arbitrarily long. I usually do something like six months or December 31st of the current year.
At this point, I just do the development that I put together for the sprint period. As a note, I ensure that everything I want to do has a specific design task written and that is a prerequisite before writing or working development tasks. I also ensure there is an administrative tasks story put in each release sprint. This is where I track things like updating social media presence, publishing the build, and (most importantly) building the sprint plan for the next sprint.
Once all the work is completed, the sprint gets edited. The completion date becomes the last day of the weekend that I’m closing out the final task and the start date of the next sprint is set to the following day. Then the cycle continues.
The way I’m developing has become less stressful from sprint to sprint since I adopted this methodology. At my day job, it would be unheard of to tie the sprint dates to the tasks within it, but the nature of the solo development caused a lot of stress when I was trying to force my tasks to fit within the more strictly-defined dates. It does make release dates harder to identify until they get closer, but since I’m the only person working on the project it’s not a huge concern.
I’d love to hear your thoughts about how you’ve approached similar situations or projects. Head over to the Discord server to start a conversation!