If working with a publisher, how do you (or would you like to) set up a milestone schedule? How do you prevent milestone crunches which include wasted work?

Robbie Edwards: In my ideal world, I would like milestones about every other month or every month. I would like to start the first day of each month detailing what we intend to accomplish or test. Then on the last day of each month, review that progress and begin again the next day. Frequent review and communications are critical in my mind and with the speed of change in our industry, it’s very difficult to remain competitive and meet expectations when those expectations are only reviewed every 3-6 months.

When it comes to preventing crunches, I am all for scope changes. I adamantly feel that realistic planning and frequent project evaluations will all but eliminate the need for crunches. Yet, crunches still happen and instead of death marching the staff, I prefer to look for low value and high cost features and start considering their removal. A tired staff is an ineffective staff and quality is greater than quantity. Having a fresh team every day putting forth their best efforts is much better than any of those small features that end up on the chopping block.

Frank Rogan: Milestone schedules should be oriented around usable results. Prototypes delivering XYZ feature, alpha/beta deliveries with clear definitions, etc. This is good for relationships with publishers, because it gives them the real yardsticks they’re looking for. But it’s also good for team dynamics -- the team is working toward something tangible, with a shared sense of mission. Milestones for milestones’ sakes lead only to crunches and frustrations on all sides.

Gas Powered also benefits from the strong sense of mission derived from its “Skate Hard” philosophy, which places an emphasis on health and family. That’s an entirely different subject for future round tables, though. But GPG’s most recent projects have been remarkably crunch-free, relatively speaking.

Adrian Crook: Relic is wholly owned by THQ, so there is somewhat less emphasis on formal milestone reviews with our publisher than in a traditional dev/pub relationship. We are still quite strict with our sprint review meetings, however, where we gather the whole team to review the work completed by each scrum team.

At the end of each sprint, there is a bit of a mini-crunch - maybe a few days of more intense work - where each Scrum team is putting extra love into their work for the sprint review. But overall we make it a point to avoid the kind of crunching that has people working weekends or late into the night. You pay a price for that kind of crunching that isn't commensurate with the short term benefit, if any.

Peter O'Brien: I work directly with Microsoft to setup a schedule but the first stage is internal; getting the team leads/management involved at this stage is important. I’ve tended to drive the schedule creation process and then look for publisher sign off. The fact of the industry is that a publisher wants visibility on at least a monthly basis.

However, 4 weeks for a milestone is unrealistic, 6 weeks is tough but manageable. I think it’s important that you are honest and show a strong vision for each milestone. A target definition of what each milestone will contain shows that you understand the project, but if you are not careful it can lock you into unrealistic deliverables if you don’t build a flexible relationship with the publisher.

Harvard Bonin: Milestone structures are pretty standard but it's important not to allocate the entire milestone payment to the entire body of monthly work. The publisher will almost always have some issue and hinging the entire payment on one relatively small thing will put you out of business fast. Remember, the publisher wants to pay you...they want you to be successful. I like to break payments up into smaller buckets so that the developer can get paid portionally. By doing so the publisher can still hold back funds due to noncompliance but still allow the developer enough resources to make payroll!

Wasted work is really about communication. Getting the publisher builds early and often allow for changes. Simply handing a milestone over at the end of the cycle doesn't allow the developer to make course corrections mid-milestone. Communicate every day with the publisher. Every day.