Optimism in development timeline estimations and User Stories

Game (and more generally, software) developers are optimistic people.  The act of creating anything requires a certain degree of optimism, as you start from a blank file and lay down code.  The reality of coding is to take pure concept and commit it to a working system.  This never goes as smoothly as planned.  In most cases, only by attempting the work do you find out the initial selected approach is not the correct one.  I’ve seen many experienced and inexperienced developers get caught on a “light” estimate for how long something is going to take.  Often the time quoted is simply development time and does not take into account the extra required time for debugging, performance tuning, documentation and proper testing.  The first major step to taking proper estimating is to agree on what needs to be accomplished.  We often called this “writing the spec”.  I’ve personally erred on both sides of the specification equation, providing too tight of a specification which doesn’t allow the developer to leverage his/her experience and the other side, which is almost a blank ticket to write anything.  The best method I’ve run across is using a “user story” format which details who the user is and what the planned user experience should be.  This method communicates the target without laying our too many hard requirements.  In most cases, even a junior developer (with a little technical oversight) can meet the requirements as laid and and have room for creativity.

A proper “User Story” needs to do a few things:

1) Describe the user

2) Describe the desired outcome

3) Detail any “hard” requirements

4) Outline the expected effort


So here’s my example:

As a mainstream game player I can select a character on the screen by clicking on that character.

When selected the the character should:

  • indicate selection by displaying a coloured circle beneath the character.
  • indicate selection by displaying a highlight box around the character portrait.
  • execute all input commands until de-selected


This should be a basic selection system based off the existing UI system.

The system must be able to integrate with the existing party system.

Any required input code should be maintained within the Input class.

The code should compile and execute under all specified target operating systems without errors or warnings.

This system is expected for delivery in two weeks time, including testing, documentation and initial performance tuning.


The above example is very arbitrary, but I have yet to find two people who write them up the same.  What I feel is important:

  • Be specific on desired outcomes
  • Give detail when it helps solve the problems
  • Be specific on hard requirements.
  • Ensure there is a timeline clearly associated with the work.
  • If the work is taking over a month, break it down into smaller deliverables.

The best work I’ve done in this area has been when I understand well what I’m trying to describe and I use a few descriptive lines to convey the desired user experience.  You will need to adapt your user stories to fit your personal writing style, but always try to keep your eye on the end user experience.