The most important stories to do first are the ones that contain the highest business value. Beware of sequencing stories based on technical dependencies. Most of the time the dependencies are less important than the value.
One of the key parts of planning is deciding in what order you should do things. There is never any shortage of things to do. What should we do today?
Sometimes software is just too complicated, so instead let's consider something that is both more mundane and more essential. In cooking you answer this question by looking at the timing and sequencing in the recipe. Often there is quite a strong ordering involved: You have to fry the onions golden before you put in the chicken.
This notion of ordering is the dominant aspect of most kinds of planning. On big engineering projects this is what leads to the practice of dependency analysis and PERT charts. Dependencies between tasks dominate planning. Your mission, should you choose to accept it, is to find the best way of navigating through the dependencies.
To plan in this style you need to lay out a list of tasks and capture the dependencies between the activities. By looking at these and looking at the duration of the activities you can figure out the key activities on the critical path where a delay will affect the whole project. If you do a course on project management you'll usually spend a good bit of time on this kind of analysis, together with such topics as resource leveling. You may well use a computer tool to help deal with all of this.
All of these techniques are pretty much useless on an XP project. They are useless because dependencies between tasks do not figure strongly, because of the emphasis on minimal technical commitment and constant growth in the design. Most of the time there is no necessary ordering between the stories. You can build them in any order you like. We don't have proof of this, but, like most software pundits, that never stopped us from making a brave assertion. Our evidence is simply that nearly every time someone comes up with an ordering constraint, we can shoot it down.
A good example is a project Martin ran into for doing costing analysis for a factory system. The cost models were complicated and very new, so they were not well understood. They ran on a large amount of data. The project team reasoned that since the models needed the data, the software to enter the data needed to be written first. This meant building a lot of GUI screens for entering and validating the data.
That was a false dependency. The data could have been put into the database using raw SQL. This method would have allowed them to work with the costing models and figure out what the models were really about. Until they understood the models better, they didn't know what data they needed. Running the models was the point of the application after all, the data was there only to serve the models.
Most ordering dependencies are false. Of course, most isn't all. The cases where you do get dependencies, they are easy to deal with on a case by case basis, either inside an iteration where you have control or by modifying estimates midstream. They don't affect the overall plan much.
A logical, yet na¨ive, reader would see this lack of constraints as a benefit. But often it isn't. Instead, we see people who are looking for dependencies and are so determined to find them that they find dependencies that don't exist. After all, if there is no ordering constraint, how do we choose in what order to do things?
So we need different factors for making our choice. The first of these is business value. Do those stories first that yield the most benefit to the customers. This seems so obvious that we hardly feel the need to point out why. But just in case, we'll do it anyway.
We want to get a release to the customer as soon as possible. We want this release to be as valuable to the customer as possible. That way the customer will like us and keep feeding us cookies. So we give her the things she wants most. That way we can release quickly and the customer feels the benefit. Should everything go to pot at the end of the schedule, it's okay, because the stories at risk are less important than the stories we have already completed.
Even if we can't release quickly, the customer will be happier if we do the most valuable things first. It shows we are listening, and really trying to solve her problems. It also may prompt the customer to go for an earlier release once she sees the value of what appears. Early releases scare people who do prototyping, because prototypes aren't production quality. But XP never builds anything it can't be proud of, so we can deliver at any moment.
How do we measure the business value of a story? The short answer is that we don't; that is, the developers and project managers don't. Determining business value is a decision entirely within the realm of the business people. It's their business; they know what the value is. At least, they are better positioned to guess than we are. If they're wrong, well, they're paying for it. If you have enough dollars you have the right to be wrong. The developers can suggest alternatives and ask questions. But in the end business value is always a business call.
How carefully should you figure out the value of stories? You don't need to get it to the dollar; indeed, it usually isn't worth trying to put a dollar value on it at all. The relative values are what counts, and you need only a rough sense of the relativity.
This is enough to start with. As you play out the release plan, you'll allocate the stories into iterations, and that will lead to a finer determination of business value. But in order to do that the business needs some more information.
Imagine you're standing in front of the new car that you've been salivating over for years. Finally the old heap has thrown a rod and you can reward yourself with a year of that new car smell. You're finalizing the deal and the salesman asks, "Would you like the optional sunroof with that, sir?" What do you answer?
Unless you're either incredibly cheap or incredibly rich (or incredibly against fresh air) you'll want one piece of information: How much is that window in the Rover? If the cost is $10 you'd probably take it. If it's $10,000 you'll probably pass. But if the range is that big, you can't decide without the cost.
For most software, the range is that big.
So who gets to allocate the cost? Developers state the cost, and they state it by estimating how much effort it will take (see Chapter 12).
As the developers look at the stories they will inevitably start thinking about how they will build them. As they do this they will run the gamut of feelings, all the way from "no problem" to "can't be done." These feelings are important, because they are the manifestation of where the project could go off the rails. When developers feel nervous, everyone should listen.
The nervousness comes from a number of sources:
The developers may not be confident that they can estimate the story to the required precision.
A story may depend on an untrusted third-party piece of software.
The developers may not know how to make the whole system fast enough for future loads.
The developers may not know how to design today so an expected feature can be added without reworking most of the system.
In general, programmers want to do higher-risk stories first. That way, if something goes wrong, you find out early while you still have time to deal with it.
You notice we have two different criteria set by two different groups of people. How do we resolve the two of them? Programmers want to tackle high-risk stories first, and customers want to tackle high-value stories first. There are plenty of times when these conflicting priorities have to be resolved.
Business should sequence stories. Business people understand uncertainty in estimates. They face risk all the time with financial projections. They also understand the cost of reworking in the cases where reworking is an issue. If they wish to run a risk in order to get better value now, it is really their call. It is the programmers' task to make the risk visible, not to make the decision for the customer.
While this arrangement is the ideal, sometimes you need something extra to make it work, perhaps allowing developers to choose a certain amount of stories per iteration so that they can bring the risk forward.
We need to stress that you shouldn't worry too much about the issue of reworking. XP's practices are all about reducing the cost of reworking to manageable levels. If you find yourself in a situation where the cost of reworking is prohibitive, then you should either not use XP or you should use an environment that makes rework easier.
We'll confess that we disagree a little on this. Martin is much more inclined to bring stories forward due to risk than Kent is. Kent considers Martin a coward for this attitude. Martin agrees.
Let's take a look at the release plan from the time capsule. The information was annotated on the cards, but we've transposed it all into a handy table for you (see Table 13.1).
Table 13.1. Time Capsule Release Plan
| Story | Time Estimate (Ideal Weeks) | Assigned Iteration # | Assigned Release # |
|---|---|---|---|
| Find lowest fare. | 3 | 2 | 1 |
| Show available flights. | 2 | 1 | 1 |
| Sort available flights by convenience. | 4 | 2 | |
| Purchase ticket. | 2 | 1 | 1 |
| Do customer profile. | 4 | ||
| Do simple customer profile. | 2 | 1 | 1 |
| Do full customer profile. | 3 | ||
| Review itineraries. | 1 | 2 | 1 |
| Cancel itinerary. | 2 | 2 | |
| Print immigration paperwork. | 4 | ||
| Show hotels. | 3 | 2 | |
| Show hotel availability. | 2[a] | 2 | |
| Offer sophisticated hotel search. | 3 | ||
| Book a hotel. | 1 | 2 | 1 |
| Provide hotel/spaceline programs. | 3 | ||
| Offer airplane hire. | 3 | ||
[a] Is 4 if "Show hotels" isn't already there | |||
We measured the team's velocity at six ideal weeks per iteration. As you can see, stories have been assigned to iterations. There's a release after the first two iterations and a further release two iterations later. (The releases are a little short, but this is enough for an example. And in any case, there's this confidentiality agreement that prohibits us from showing the whole plan two centuries before we begin.)
There are a few things worth noting:
The "Do customer profile" story has been split up into two parts with different priorities. The estimates don't add up in this case. Often they do, but from time to time they don't. That's not an error. Each story should be estimated independently, so it does happen. Maybe breaking it apart made us realize it was bigger than we thought, or maybe doing them separately would take longer. The reason usually isn't important, so there's no need to document it.
The second iteration only has five ideal weeks of stories assigned to it even though the velocity is six. That's okay—additional work, either new stories or pieces of later stories, may well get added closer to the iteration's date.
A note on the card for "Show hotel availability" indicates that the estimate depends on other work. That's not uncommon, but it isn't worth making a fuss about. It was probably only recorded as the customer was figuring out what to put in iteration 2.
It may look odd that "Book a hotel" is assigned to iteration 2 when "Show hotels" isn't assigned yet. How can you book a hotel if you can't see the list? The point here is that the functionality won't be available to the user yet but will be built into the system and can be functionally tested to the satisfaction of the customer. Not all behavior has to be usable by the user to be included in the iteration; the key criteria is that it is testable. You'll often find this in cases where you need to build functionality in the core business logic but don't add the user interface until a later iteration.
You'll notice there are no details about the iteration length or size of team. This is deliberate to point out that you actually don't need that information for the basic release plan. All you need is the estimated stories and the velocity. Obviously you'll need the current date and the iteration length to tell people when an iteration will be done. Something along these lines as shown in Table 13.2
It's comforting to know that even in the twenty-fourth century people will be using two digits for the year.