"Hey! When is Archmage Rises going to be done?!?" - Everyone I meet, everywhere
Last Sunday I was at a potluck. The person across from me asked the natural polite question I hate answering: "So when is the game going to be done?"
Scheduling Software Is Hard, Indie Games Harder
In this video update we show how applying some best practices, previous experience, and a little old fashioned flubbery we have calculated a feature complete date for the game!
We start with analyzing the core features:
I then spent roughly 10 hours analyzing the state of the current code base and work to date to figure out what still needed to be finished, made, and designed.
That resulted in a series of SCRUM stories I made up in Visio. To keep things sufficiently "macro" I limited myself to just four bullets to describing the story. While this was often difficult, it was a good practice to keep this a useful scheduling diagram and not a design document in another form. Nic and I then estimated how much effort (in days) it would take in design (idea. layout, content) and implementation (UI, coding).
The next step was to prioritize the features. Sometimes priority is based on pre-requisite, or what has to be in the game if funding got cut and only half of it could be done. This was difficult to decide for "my baby". In the end I color coded them across 5 levels of priority. I then grouped same priority into swim lanes so I could tell if I had put 20 as top priority and only 1 as bottom priority (which I did, but the swim lane showed me I was being silly). When done the ~30 stories were split evenly across the priorities.
At this point we had a good handle on the mountain of work in front of us, but still no closer to a date. WHO will do WHAT and WHEN? This took another 5-6 hours in MS Project to gantt chart out. I didn't have project installed on this laptop and there were challenges to finding my legit copy, so I tried some free gantt solutions (Tom's Planner, GanttProject). Those were a waste of time: so simplistic as to be useless. One doesn't do dependencies driving start dates, and the other won't let you drag and move a task around in the schedule. Then there were problems putting in non-working days by project, split tasks, and multiple resources on the same task (2 people on a 10 day task is 5 days calendar, not still 10 days GanttProject!) In the end I managed to find my Project and get it installed.
Then There are the Unknowns
An Unknown are unanticipated things: bugs (ours and Unity's), impromptu meetings, misunderstandings, rework, finding the fun, illness, new Star Wars film, catastrophic disk failure, etc. And those are just the common ones!
So how many unknowns are there between now and finishing the project?
If you said "It's unknown" you are correct! So we know something bad is going to happen, probably repeatedly, so how do we account for this?
At my software company, across many years and many projects, we discovered scheduling a 5.5 hour day was the most realistic/accurate way to schedule effort vs calendar. My calculator says that's about 68% efficiency; reasonable for a 10 person team. Smaller teams are more efficient (less meetings, less misunderstandings), so we went with 75-80%. The actual way we implemented it was by scheduling "3 weeks on 1 off".
I could have simply added 25% to all estimates, but I did it this way so we have a one week gap in the schedule for testing, polishing, content filling, bug fixing, and possibly pushing out a release. The gaps are easier to schedule around and track slippage than simply adding a blanket %. Second, if your 10 day task says it will end in 10 days not 13, that helps keep to the original estimate you gave. It's a psychological trick to keeping people honest and self correcting on estimates in the future.
This resulted in our grand project plan:
This is the most accurate and realistic date we have ever published.
Now if you find yourself at a potluck with someone asking when Archmage Rises will be finished, you can answer!
"And knowing is half the battle, yo Joe!"