Full Product Planning

Another question:

It also doesn't seem terribly useful for estimating the scope of the entire project. Somewhere early on, independent developers have to tell their publishers that they're going to have n levels or stages or whatever, each about so long, and their full-production milestones usually revolve around the delivery of some number of levels. Scrum seems to only be looking a month into the future, so how do we do this part of the process?

The portion of Scrum I focused on in the talk didn't cover long term planning. The main reason for this is that we transitioned to Scrum halfway through the project (a year ago) and didn't get to go through the entire process. However we did manage the product backlog and had experience in using it to manage risk and some planning.

Full production planning (of the product backlog) is a part of Scrum and Agile in general. From what I've read it seems to be able to create a product schedule that you can have far more reliability in than your typical waterfall schedule.

One key point about Agile is its focus on creating product value early. If you look at page 7 of the presentation you'll see the goal of an Agile Project (red) is far steeper than the waterfall curve(blue). This is achieved by placing greater value on working software than a document or schedule.

The long term list of goals and the resultant plan for implementation (including a timeline) can be derived from the product backlog. This backlog is much the same as a document of features except that it is a database of features than can be prioritized and "burned down" by Sprints. One major element of the Scrum I did not talk about was its fractal nature. Look at pages 40-42 of the presentation. This shows a Sprint burndown. You can also "burn down" the product backlog. Since every item in the product backlog has an estimate and you remove some of those items from the backlog every 30 days, then you can produce a chart which shows you how you project is progressing. If your burn-down is slower than your ideal, then you can reduce scope (remove the lowest priority N backlog goals), increase the X axis (get an extension) or increase slope (add more people....the worst choice of all).

In waterfall methods, demonstrated value is delayed a bit more. This can result in core tech being implemented later in the project. This leads to projects entering a "production" phase earlier than they really should. This can lead to delays if the assets need reworking or the release of an unfinished game.

Agile planning (again, speaking from what I've read and not fully practiced) focuses on scheduling what is known and timeboxing/prioritizing what is not. It seems to have better tools for managing risk.

Detailed schedules and docs may give everyone a warm and fuzzy feeling when they are written but like a battle plan, they don't survive first contact with the enemy (in our case, noise).

As we take on planning for our new projects over the next few weeks/months, I'll post feedback here.