Communications Lab 4

CIS 300 Fall 2006

Thursday, September 21, 2006 

The Milestone Document 

Typically the timeline for developing software, games or otherwise, is divided into what are called “milestones.” Milestones are important markers that signify the completion of crucial tasks in the development cycle. The development team creates a Milestone Document, detailing the specifics of each milestone. A typical set of milestones for game development include:

• Project Kickoff
• Design and Functional Specification Draft
• First Production Milestone, Second Production Milestone, etc.
• Code Complete
• Content Complete
• Zero Bugs
• Release

Each milestone should be described specifically in the timeline, and typically has the following detailed:

·        A title

·        A short description

·        A due date

·        Production dates

·        A test for acceptance

·        A risk assessment

·        Deliverables

·        Contributors 

For this class, the Milestone Doc won’t be quite as detailed as one in the industry. Given the iterative nature of game development, we’d like the Milestone Document to be somewhat broad and flexible. It will list broad tasks for the entire semester, and conform to the schedule below: 

Additionally, every two weeks starting with the completion of the Gameplay Prototype, we’d like each group to provide us with a very detailed two-week breakdown of tasks leading to the next boldface milestone. By very detailed, we mean down to an allocation of all hours of each team member. Recall that each group member is committed to 10 hrs/wk of work on the project. This means that for each two-week period, the project leader has 20 hours of work to allocate to each member of the team. Your two-week breakdowns must account of all of those hours. We will talk more about these breakdowns next week.

Today’s tasks: 

1)      Jerry talks about the Milestone Document

2)      Each group begins work on the Milestone Document: 

We’d like you to get started today on putting together the Milestone Document. Instead of organizing your initial work by deadlines, try to begin by just generating a list of all the tasks you know you’re going to have to do to complete this project, including the sub-tasks necessary to complete the larger tasks.  After you’ve gotten the list of tasks and sub-tasks to a place where everyone is satisfied that, as of now, the list is exhaustive, then you can begin to match those tasks with the calendar.  

When you reach this point, an important consideration will be structure.  How will you organize this information so that the information you are trying to convey (what is going to get done, by whom, when, etc…) is transparent to your audience.  As with the Game Concept Document—and just about any other document you will write for a professional audience—the Milestone Document needs to be skimmable.  That is, a very quick glance at even the first page should reveal to the reader how information is organized in the document.  Don’t make your reader work anymore than they already have to. 

One final note: you can think of the level of detail that a Milestone Document should include as the level of detail that the team leader would be able to understand. Anything more detailed than that belongs only in the two-week breakdowns. 

3)   During 2, Jerry and Mohan will review with each group the Concept Document Drafts submitted for Comm Lab 3.5

4)   Turn in the "task list" created in 2) to CMS.

Follow up tasks: 

By Monday at midnight, submit a draft of your Milestone Doc to Comm Lab 4.5