This post originated from an RSS feed registered with Agile Buzz by Keith Ray. Original Post: What == How Feed Title: MemoRanda Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics. Latest Agile Buzz Posts Latest Agile Buzz Posts by Keith Ray Latest Posts From MemoRanda

One of the premises of writing user-stories for XP and other agile methods is the that story -- as written -- should not get into implementation details. However, the conversations between Customer/Product Owner and Developer and Tester can and should concern themselves with implementation details.

An example of a user story (from an article(pdf) by Mike Cohn is "A user can remove her resume from this site". That seems to be a "what" because it doesn't get into the details how the user performs this action. But this is a "how" when considering a higher level "what" -- "the user has wants to stop the job-hunting process". From that perspective, maybe an appropriate lower-level story, that we haven't considered yet, is "the user can close their account with this site."

At yet another higher level, the "what" story is "this company can make money by hosting a job-hunting web-site." Or maybe this is a non-profit? What stories would be different if this a for-profit venture rather than a non-profit venture, or vice-versa? If non-profit, is this backed by a church, a government, a co-op, or another source of funding, and what requirements do these funders have? If this is for-profit, is the money coming from the job-seekers, the job-posters, or both? Do the venture capitalists, who are providing the initial funding for this venture, have requirements that the current set of stories don't address?

Ron Jeffries and others the XP mailing list, have often recommended breaking down stories into very small ones that can be easily estimated. While the original XP project and early books recommended breaking stories down into tasks, with programmers signing up for tasks rather than stories, most agile gurus now recommend smaller stories, with no formal breaking down into tasks (though doing so informally can help with estimating the story.)

There is an example of breaking a large story down into smaller stories in an article (pdf) by Mitchel, Auernheimer, and Noble, which I quote:

The owner of a business process uses their web browser to look up a list of processes on the server, select a process they would like to invoke, fill out a form and submit it to start the process. A participant assigned a step in the process uses their web browser to retrieve the task description, which includes the data values entered by the process owner.

...It's too big to estimate... smaller stories...

1 The owner of processes can use their web browser to see a list of processes they own.

2 The owner can select a process they would like to invoke and do so.

3 The owner can fill out a form for the process before submitting it.

4 The process participant can log into the system.

5 The process participant can see a list of tasks to which they've been assigned.

6 The process participant can see a specific task.

7 The process participant can see the data entered by the process initiator at process invocation time.

In the ensuing conversation, story 4 is rewritten to use the user's Windows NT name and password, so they don't have to log into the web app after logging into their computer, and prioritized lower than the other stories, so in the first iteration no log-in is required at all.

By the way, there are a bunch of good papers on user stories at the Agile Alliance web-site. And Mike Cohn has two books on user-stories, both good: User Stories Applied and Agile Estimating and Planning.

The topic of "what == how" reminds me of the Theory of Constraints thinking tools known as "cause-effect-cause" diagrams. An item in such a diagram is usually both an 'effect' from some other 'cause' and a 'cause' to another 'effect'. An example here (see Figure 6) has 'Furnace walls need cooling' is an effect of two causes, 'it is necessary to heat the furnace to a high temperature (to melt the ore)', and 'the furnace wall cannot operate at a high temperature', and itself causes the effect 'cooling is achieved by circulating water'.

Similarly, the 'what' of the user is to 'kick butt', to achieve success in some way, (see the Creating Passionate Users blog) and the 'what' of the developer is to 'make money', or achieve success in some way. The 'how' is the product that the developer makes and sells, and that the user users, and that is also a 'what'.