Posted On: 2019-12-09
A couple of weeks ago I wrote about some of the difficulties I was facing while trying to get the input system to support rebinding controls. In that post, I briefly mentioned that I was at the point where I was confident that I could not accurately estimate the remaining work to complete that feature. This past week, I managed to (finally) finish it, so I thought it would be a good time to do a retrospective - focused especially on what went wrong with the estimation.
Before estimating, I normally try to have a big-picture goal, which conveys the business value for whatever I will be working on. For the input system, this was a short narrative about accessibility:
Controls that are intuitive and comfortable for some players may be awkward, or even impossible, for other players. As a designer, I have a duty to lower that barrier, and the most inclusive way to do so is by allowing the players to define what controls work best for them.
Armed with an understanding of what I wanted to do and why, I then try to break down the goal into parts that are individually actionable. For teams that use Scrum, these individual parts work well as user stories. Since I am (presently) working by myself on this project, I tend to keep this part simple, often to the point that I don't write it down (occasionally jotting down a couple keywords to remind me.) While I didn't write it down at the time, the following is (roughly) what I had in mind for breaking apart the input system:
While breaking apart larger work, it is often useful to separate research and execution: research work (such as "Determine how to rebind input") is generally quite difficult to estimate, so each one carries a significant scheduling risk. Execution work, on the other hand, often carries synchronization risk: any assets (such as art or sound) must be available during execution, and having multiple execution tasks running at the same time introduces extra work (in the form of merge or integration bugs.)
In addition to breaking apart the work, I will typically establish estimates at this point. In Scrum, it is expected that each story will be estimated individually, according to the size of the work. While I don't personally follow Scrum, I do make quick size estimates for individual items, which I then use to inform my larger estimate for the entire body of work. While working solo, I like to estimate the entire body of work using wall-clock time, rather than man-hours or sizes*. For the input system specifically, after looking over what needed to be accomplished, I estimated a bit over a month would be enough for everything.
One of the pitfalls of separating research and execution, however, is that sometimes one discovers unanticipated issues during execution that forces one to re-open previously completed research. In my experience, this is the primary source of delays: execution tends to have a tight timeline (to reflect its ordinarily predictable nature) so there is no room for additional research on top of that. Ideally, these should be rare and the scheduling problems should naturally sort themselves out over time (such as other tasks taking less time than anticipated.)
If, however, this re-opening of previous research happens multiple times during a single execution, that is typically a sign of mistakes during the planning stage. If one incorrectly divided up the research, or had an aspect of research that was not anticipated, then it can lead to massive delays. From what I have seen, this typically happens when planning before one is familiar with the underlying technology: any such plans will, necessarily, make assumptions about how the work is structured, and will be unaware of any of the architectural or design quirks that the technology carries with it.
As you may have guessed, this is exactly what happened to me while working on input rebinding: when planning, I was completely unaware of the advanced binding types (such as composite or synthetic). As a result, when it came time to execute on creating the screen, I found myself repeatedly revisiting my research (as documented earlier.) Furthermore, since I was unaware of the advanced (but required) aspects of the new input system, all the research was estimated naively, and thus I didn't have any over-estimates to absorb the overrun.
Finally, the last pitfall I face is the changing estimation process for execution tasks. As mentioned earlier, execution work requires increased synchronization across multiple people, but as a solo developer this is not an automatic win - instead, it represents the need to take off the programmer hat to don others (artist, sound designer, etc.) While doing so had small time costs compared to the additional research, my original estimate didn't account for this* - so I will need to be mindful of this in the future.
Looking at what I have done, two areas of improvement leap out at me. The first of these is that I should take the time to update estimates after performing initial research. Since the first task was (roughly) "figure out this technology" it was almost inevitable that the estimates I created before that task and the estimates after that task would be quite different. I expect that I could have anticipated some of the issues (especially with composites) if I had stopped to replan after completing the initial research. Perhaps most importantly, the flexibility to replan and readjust my schedule is a key advantage to my (very loose) planning style*, so I really should be taking advantage of it wherever it makes sense.
The second area to improve is really a bit of documentation. While working on this retrospective, I discovered that I only started documenting my remaining work when I discovered I was behind on my estimates. As such, it's a bit difficult to say how long it truly took (since I have no record of starting) and, perhaps more importantly, I don't have an accurate record of what I thought the work looked like when I first started**. Additionally, when the work started to really drag, I found that maintaining a list of remaining work was both helpful for remembering everything, as well as useful for improving morale (since the change history*** clearly showed that I really was making progress.)
This concludes the retrospective for my most recent feature: supporting rebinding controls. I hope that this examination and revision planning process has been helpful (or at least interesting) for you. As always, if you have any thoughts or feedback, please let me know.