Questions About Xp Stories And Tasks

I have some questions about the relationship between stories and tasks (as they occur in Xp). Hopefully, these can be collected here and someone will answer them.

: Q: Are there any "rule of thumb" cardinalities or can a single EngineeringTask be derived from one UserStory or one UserStory provoke one or more EngineeringTasks. Or is it somehow important to have a one to many relationship between a UserStory and EngineeringTasks?

A story the way I write them seems to provoke between three and six tasks. Many of my clients write much smaller stories than I do, though. --KentBeck

: Q: What is the difference between a UserStory as a scheduling unit and an EngineeringTask as a scheduling unit? At first I thought that stories describe requirements, are then broken into tasks, and then the tasks become the unit of scheduling. Now I've read some text that refers to using the story as the scheduling unit. Could someone elaborate on this relationship a little?

The story is the customer's boss' scheduling unit. The task is the team's scheduling unit. Task progress is visible to the customer (so much so that RetailAspect insists that only customers can check off tasks as completed).

: Q: Can a simple UserStory be its own Task or should a UserStory always be broken into one or more EngineeringTasks?

It can be its own story.

I'm not sure I understand this. My guess is that a UserStory can never also be a Task. Instead, you can simply create a single Task whose wording very much resembles the Story.

: Q: Can one create an EngineeringTask that doesn't have a direct correlation to any UserStory? Say you are writing an EDF Scheduler that will be used at such a low level that it does not belong to any *one* specific UserStory. Maybe even a better example is an EngineeringTask to set up the VCS or other CM tasks you want to schedule explicitly in an iteration?

answers

I'm going to preface this with the warning that I'm still the new guy on the block. Engineering tasks seem (to me) to be statements of what needs to be achieved so the story can be written. There is no need for correlation beyond the notion of "this is what needs to happen for this story". However, if you can not directly tie a task to a story, then it'd be easy to say YouArentGonnaNeedIt.

Q: If you do like to DesignWithPictures?, should you be designing the UserStory, or are you rationalizing the EngineeringTasks that come from that Story. I can see a progression something like the following:

Select a UserStory
Model the story with one or more CrcCards, Class Diagrams, StateChart? Diagrams or whatever design medium you prefer
Now break up the design into EngineeringTasks

I suppose this seems interesting to me only because it makes upfront design work an optional step that you can neatly wedge between Story and Task so that the EngineeringTasks end up falling out of the DesignArtifacts? rather than the UserStory. However, I've heard other prefer to say that (when and if they do any upfront modeling) they prefer these to model the Tasks rather than the Story the tasks come from. Let me insert here that I know development is fuzzy, and you can do it either way or both ways. I'm just curious to know, psychologically (or even aesthetically), how Xp would view the archetypical series of (iterative) steps.

I see lots of design work happening during task breakdown- "Okay, we need to send both email and fax, so we'll have to make the Transport into an object (task), make the FaxTransport? (task), add a GUI for the fax number (task), and put it into preferences (task)." Was this planning or design? Both.

This is all I can think of right now. Do not feel restricted to answering these questions. This is Wiki, so feel free to add new questions. I'll also try to add more as they come up. While some may have obvious answers, it is sometimes helpful to point out the obvious.

See: UserStory, EngineeringTasks, StoryCards, TaskCard