Hi Jeff,
We devote an entire chapter to planning-related practices, 70 pages, and cover the material thoroughly.
There are a lot of different components to scheduling. First, you have a choice between "scopeboxed" schedules or "timeboxed" schedules. Scopeboxed schedules release when all of the planned features are complete, adjusting the release date to match. Timeboxed schedules release on a particular date, adjusting features to fit.
We recommend timeboxed schedules in the book for two reasons. First, they're a lot less risky. Second, they force you to make hard tradeoff decisions. These decisions are a good way of weeding out the less valuable requirements that invariably get added to any software project. You only ship the most valuable software, and you do it on a specific, predictable date.
So in a way, scheduling is easy in the agile world. Pick a date. Ship your software on that date. Done.
Okay, it's not
quite that easy.
To make this work, you have to develop software in such a way that it's always technically ready to release. (Our "Releasing" and "Developing" chapters talk about this topic.) Many people develop software by technology: they develop the database layer for all of the features, then the UI layer, then the business layer, and so forth. This means that the software can't be released until all of the layers and all of the features are done.
Agile methods develop by feature: they develop the database, UI, and business layer for one feature, then for another, and so forth. This is a little harder technically but it means that the software can be released after each feature. Most agile methods work in iterations that are one to four weeks long. They are also timeboxed: in an XP project, for example, you are always finished and ready to release on, say, Wednesday morning.
Now,
technically ready to release on Wednesday morning doesn't mean that you'll
actually release. The other component to this is managing your priorities so that when your release date comes you have something worth shipping.
There are several aspects to this planning effort. First, you have to have a good overall understanding of what you're building, why it's valuable, and what success means for your project. Our "Vision" practice addresses this need.
Second, you need to determine what the "minimum marketable features" of your product are. A minimum marketable feature (MMF) is something that has value to the marketplace. The "marketplace" can be paying customers or internal users depending on what kind of software you're developing, but either way, an MMF provides value. MMFs are also small ("minimal"), which is important, because small features are easier to finish quickly, which reduces the risk that you'll throw away partially-done work on the ship date.
MMFs in turn are broken down into stories, which are bits of MMFs that represent recognizable progress to your business experts... the people XP calls "on-site customers". It's important that stories be customer-valued because that's how you demonstrate progress that everybody can understand.
Stories can be estimated extremely accurately. Well, sort of. This is actually a simplification. The estimates are not at all accurate, but when combined with slack and velocity, they lead to very consistent and predictable iteration schedules.
So a naive approach would be to identify your vision, brainstorm MMFs and stories, estimate them all, and build a schedule based on those estimates. In a perfect world, that schedule would be accurate.
I'm tempted to leave it at that, but in fact it's not that simple. Reality is messy. First, even if you did brainstorm all of those MMFs and stories--and you shouldn't (see below)--your consistent iteration schedule won't always come true. People get sick, there are unexpected events that disrupt your work, and so on. These risks reduce the amount of work you can finish before the deadline. We have a section on risk management that tells you how to predict schedules in the face of risks. We provide some simple arithmetic that will give you probability curve for how much work you'll get done. In other words, you'll have a 10% chance of getting X amount of work done, 50% chance of getting Y amount done, and 90% chance of getting Z done.
With these numbers, you can then say: "We will ship on this date no matter what. On that date, we will almost certainly have Z features done. We will try to get Y features done, but it's a stretch. It's almost impossible for us to have more than X features done." Then you actually do ship exactly on your ship date and you nearly always have features done in the range that you promised. And, as each iteration completes, you get more information that tightens and improves your predictions.
This is already far beyond what you see in most projects, but it's still rather simplistic. The big problem with everything I've told you so far is that it's static. It assumes that your plan is made at the beginning of the project and never changes. But in fact, your initial plan is your worst plan, because it's made at the point when you have the least information about how people will react to your software. You can add a lot more value if you change your plan as you learn new things.
One of the big advantages of agile development is that it allows you to change your plan. This leads to a technique called "adaptive planning" that is very cool, but I don't have time to go into right now. The nutshell version is that you actually seek out opportunities to learn new things and take your plan in unexpected directions. You do this because it allows you to increase the value of your software. For example, when my wife and I traveled to Europe a few years ago, we used adaptive planning. When we were in Italy, we discovered that our plan to go to Turkey would take too long, so we went to Prague and Switzerland instead and had some of our most memorable experiences. We increased the value of our trip because we weren't locked into an up-front plan.
There's much, much more to this, including a technique of tiering your planning horizons to reduce planning costs, but you'll have to refer to the book for the details.
