Tell Me a Story, Daddy


This definition of user stories is given by Ron Jeffries: [4]

A UserStory is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. The UserStory promises as much subsequent conversation as necessary to fill in the details of what is wanted. The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation.

Therefore, a good user story is one that can be estimated, prioritized, implemented, and tested . Often, a single user story must be broken down into smaller stories in order to fulfill these criteria.

User stories in XP double as a form of task list (see Figure 10-1). (In fact, the stories themselves are divided into smaller, piecemeal tasks that are easier to allocate and estimate.) The customer decides which stories will be in the next iteration. Then the programmers sign up for specific tasks, depending on which stories interest them the most, which tasks they feel the most technically able to implement, and so on.

click to expand
Figure 10-1. User stories form a list of deliverables

The possible scope of any user story is pretty much wide open . If you can fit it on a story card, then it s a user story. However, to be a good user story, it must conform to the criteria that we describe later in this chapter ”in particular, it must be testable and estimable (i.e., you should be able to predict how long it would take a programmer to code on an ideal day). Thus, a user story may define either functional or nonfunctional requirements (as long as they can be tested).

On the Extreme Programming discussion group on Yahoo, Ron Jeffries describes the fundamentals of a user story as follows :

Every function that you are going to program needs to be /covered/ by a story. Remember that a story is

Card ”planning token for estimating and scheduling

Conversation ”transmission of the understanding of what has to be done for this story

Confirmation ”customer test showing that the functionality for the story is working [5]

In the same message, he adds

The examples in XP Installed are mostly /larger/ than what I would do now. Your stories only need to communicate between you and your customer.

This drives home a couple of issues:

  • Individual user stories are very, very small. They aren t intended to convey very much themselves; they are memory joggers, nothing more.

  • The detail of the user story is in the verbal conversation held with the customer (i.e., it s not written down, except in the acceptance tests).

The quote from Robert C. Martin at the start of this chapter was in response to somebody s suggestion that it might be prudent to use a program to store your user stories, because you cannot afford to lose them. Martin s response began , Yes, you can.

We humbly suggest that this is another risk-increasing aspect of XP. In our projects, it has never been okay to lose a requirement or to hope that if it s been forgotten that it wasn t too important. Fingers crossed, eh?

It s safe to say that if your project is for a hospital system that tracks patients medical records, you wouldn t take this approach. Every user story, every requirement, will have gone in there for a reason. It isn t sufficient to simply say, Let s hope that none of that stuff we forgot was important. There needs to be a catchment system, some form of contingency, to ensure that nothing is missed, and that if a user story is left out, it s for the right reasons (i.e., the customer decided to leave it out, he didn t simply forget about it).

Another way to phrase this is, If your project is really important, you wouldn t follow the Extremo advice of it being okay to lose written requirements.

start sidebar
Symbolic of a Greater Problem

We revisit the losing a story card issue several times in this book. You d be forgiven for wondering why we keep returning to it!

The issue isn t so much with the dangers associated with losing a stack of vague, loosely worded story cards ”the issue is that this particular practice really sums up the XP attitude to contingency. It s symbolic (if you will) of the cowboy philosophy that s woven throughout XP: It s okay to lose story cards because they probably didn t matter. In a similar manner, it s okay not to write things down in detail because enough people should be able to remember, it s okay not to elicit the requirements in detail because we can just ask the customer as we go along, it s okay not to design for the future because we can just change the design when we get there, and so on.

end sidebar
 
start sidebar
Being Negative

On the C2 Wiki site, there has been some discussion over what really constitutes a user story. For example, can a user story be written in the negative, as follows:

The importing of invoices shall not corrupt the database.

This example cannot reasonably be implemented by a programmer, so it would need to be broken down into more user stories, which are likely to be written in the positive:

The invoice importation process will include a data validation stage, which prevents incorrect or corrupting data from being written to the database.

Any data written to the database in multiple writes will use transactions, so that the database is never in an incomplete state.

In the non-XP world, high-level requirements can still be written in the negative-( The user shall not be allowed to cause a system meltdown ), so the customer s actual requirements may still be captured in a style and format that s natural for the customer, without having to translate them into something more suited to developers.

If, in addition, the system functionality is captured as behavioral requirements (aka use cases), then the problem wouldn t arise. It should be possible to implement each and every use case because there s a clear and logical path from use cases to code.

start example

We discuss this logical design process in Chapter 8.

end example
 
end sidebar
 

[4] Ron Jeffries posting to the C2 Wiki page User Story, http://c2.com/cgi/wiki?UserStory.

[5] Ron Jeffries posting to the Yahoo group Extreme Programming, http://groups.yahoo.com/group/extremeprogramming/message/68531, subject: [XP] Stories, January 10, 2003.




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net