Stories for Initial Release | Javaв„ў EE 5 Tutorial, The (3rd Edition)

Extreme Programming teams deliver running, tested software to their customer frequently. How frequently? Every iteration, ^[4] which means every week or two weeks, depending on the chosen iteration size . Obviously we cannot implement the customer s vision in a week. What we can do is pull out the essential ideas that make up business value in the customer s mind and focus on implementing the most valuable and important features, or the features where the customer will learn the most about what he really wants.

We begin by summarizing for our customer what we have learned so far.

Rich Text Format is difficult. We do not know how to edit a page that looks just like the target Web page, in place. We have two approaches that might work. We can use the RichTextBox control in .NET. This has the ability to display most anything we could want. The Rich Text Format language is complex and not easy to understand, though we can probably do most of what we need somewhat by rote, just putting canned text items into the page. The results wouldn t look just like the resulting Web page, but it could be made to look pretty good. We believe that it will take a week or two of our time to get a credible example running and probably three days to do enough experimentation to provide a better estimate.
Direct rendering is also difficult. In the Petzold book, we found lots of information about rendering various kinds of text directly into a simple form, and there is even information about how to draw lines and curves. We could use that approach to put together a simulated Web page. Like the Rich Text Format approach, it wouldn t look perfect, but it should be pretty good. We would need about three days to experiment with this, and we think it would take a week or two to get it running.

Editing the file. Our experiment included the basic connection between the form and the keyboard. We just made the program enter controlP when a Ctrl+P was typed, but that was enough to tell us that we could readily make it insert <P></P> or other XML tags. We think we could build a little XML Notepad clone that did smart things as you type; each feature that was just a text edit would take a day or less. This wouldn t give a fancy display, but the user could use the existing approach of generating the HTML and looking at the results. An easier way to see the display could be done later. We think that would take a few days as well.

Lesson

Notice the vagueness of these estimates, which is typical when we re starting out. Also notice that we have some easy stories and some stories that are much harder. Three times harder, perhaps even five or ten times harder. This level of understanding is usually enough to enable a team to figure out the next couple of weeks effort at the beginning of a project.

Our basic recommendation to our customer is that we can make the editing job a lot easier by using a simple notepad approach, and that we can address the vision of the more beautiful WYSIWYG format later on. We re willing to go ahead with the graphical part first, but if we do we ll have to break it down into smaller one-week chunks . We think the simple editor approach is a good way to start, because the XML editing approach we are replacing is a neat little product named TextPad ( http://www.textpad.com/ ) that we use to enter our XML. I m typing into TextPad right now. We have a few TextPad macros defined such that getting to the next paragraph or heading isn t too hard. But TextPad doesn t understand what we re really up to.

We propose a starting version of the customer s vision that works like a smarter TextPad, one that understands a little more about what s going on and is more helpful with the editing. We talk about it and come up with the following stories:

When we re typing a paragraph inside P tags and we hit Enter, create another P tag underneath this one and put the cursor in between the new tags in the right typing location.
When we re typing inside P tags and we want the line to be, say, Heading 2, typing Ctrl+2 will remove the P tags and replace them with H2. When we hit Enter inside H2, create a P tag underneath the H2 line and put the cursor inside it.
Same as H2 for H3.
Start the editor (File/New) not on an empty page but on an empty template for my Web site. Put the cursor inside the first unfilled tag so that we can just start typing the title or whatever it is.
When we type Tab in the editor, move the cursor to the next tag (or maybe the next unfilled tag). We ll have to try it to see what works best. Think of it as tabbing from field to field in a form.

At this point, we re not estimating these stories in much more detail beyond OK or too hard. We think each of these can be done in about a day of work. Certainly none of the above are too hard, unlike some of the ones in the initial vision. These stories are more than enough, we think, for our first iteration and first release. We agree with our customer to work on these.

Our customer is now imagining a product like TextPad. It s a Notepad-like product, but when the user types into it, the editor automatically updates the XML in ways that are more convenient, and more intelligent , than NotePad can do. We all know that the desire to view what the page will look like will come back. We also know, however, that the customer has a perfectly good, but not entirely convenient , way to do that now. We agree that the best first task is to get some editing working so that the customer can see that we re making progress.

Lesson

Now in a real XP project, with a live customer, full-time programmers, and so on, we would put together two plans at this point. The Release Plan would consist of looking at all the stories in the whole product, estimating each one, and laying them out on a table to see how long the whole project might take. We wouldn t be very accurate in the first couple of days, of course, but we d be able to get a good sense of the project right away. And over time we would review and revise that Release Plan by using the results of our work so far to improve estimates.

In addition, we d do an Iteration Plan at the beginning of each two-week iteration. That plan would include a bit more detail on each story, our envisioned tasks , who was planning to work on each one, and so on. Not a big deal, but some notes on the whiteboard to make sure the whole team has the same understanding.

The focus of this book, however, is on how the programmers develop useful software while learning. So we ll remark on things like the Iteration Plan, but our focus will be on figuring out what stories we can do, estimating them closely enough to be sure they re small enough, and then building the software in a way that shows value to the customer and keeps the design good and improving.

^[4] XP developers develop software in iterations, fixed time boxes that are typically one or two weeks long. In every iteration, the team produces running, tested software that can be understood as offering business value to the customer. Not just infrastructure; real, running, somewhat useful software.