An Extreme Programming team works in very small requirement chunks that we call stories. The best XP teams today are breaking work down into stories that can be accomplished in a couple of days yet that offer visible bits of business value to the customer. There can be a lot of skill to this, and while it isnt the main theme of this book, youll get a feeling as we go forward for how to turn a large and complex requirement into small, simple things you can actually do.
Recall our initial vision of a wonderful WYSIWYG editor where you are editing right inside your browser. How do we begin to help the customer decide what our first release of software should be? The basic rule in XP is this: the customer decides what features would be of business value. The programmers help the customer break down features into stories that are small enough to estimate, test, and implement. Then the programmers estimate the cost in time of doing each story. Based on her understanding of the value and the cost, the customer decides what will be worked on, in iterations of a week or two. At the end of each iteration, the programmers deliver to the customer running, tested code that implements the stories for that iteration.
Now we cant fully simulate that process here, and in fact our purpose is to explore how to build software in that short, iterative style and yet have a good design right along, not to simulate all the aspects of XP. But to do that, we had to select some stories to start with.
We did some reading and Web searching to find out about editing in a browser and about Rich Text Format. We believe that WYSIWYG editors such as Microsoft FrontPage are probably editing in a RichTextBox, or else they are rendering everything directly in graphics. The Petzold book shows code that displays various fonts with direct graphics, so we got a good sense of how hard that would be. Our conclusion was that direct rendering would be difficult and time consuming but not impossible . Our conclusion on Rich Text Format was that the specification is huge and hard to understand, but that the RichTextBox can surely do everything we would need for WYSIWYG display if thats what the customer wants. So we suggested to ourselves that a Rich Text Format pane might be a good approximation and perhaps much easier to implement, and we did a brief spike with an RTF pane to get a sense for whats possible. We found that the RTF format itself is far more complex than either XML or HTML.
Now the point of our software product is to deliver business value, which in this case means easier editing of the XML that makes up the Web pages of XProgramming.com. On the basis of what we know from our experience, including these spike experiments, we want to work out some detailed stories with our customer.