A UserStory is scheduled to be worked on in the current Iteration. With the team, brainstorm the things that must be done to accomplish the UserStory. Each of these is an EngineeringTask. Make each task small enough so that everyone understands what it means and so that everyone can estimate IdealProgrammingTime to complete it.
Give each EngineeringTask a short name for writing on the board and IterationPlan. The Engineer who signs up may write more description on a card to remind her what is to be done. If created, an Engineering Task Card is not a tracked document. The task, however, is tracked.
Different Engineers will have different estimates for the EngineeringTask. The Engineer who ultimately signs up for it (see IterationPlanning) uses her own estimate in the IterationPlan.
Example of transformation from UserStory to EngineeringTask:
The customer provides a user story:
Engineers then brainstorm the engineering tasks for the story. A CrcCard session would be used to help generate the tasks if they were not obvious. Tasks at the level of those here would now (2 years in) be obvious to the C3 team in more than 90% of the cases. Early in the project, we would have CRC'd something like this.
Where does that last EngineeringTask come from? I don't see it in the UserStory; did it come from further conversation with the customers?
I've come to distrust any individual task estimate over 3 ideal days, but we currently allow estimates up to 5 days. Anything larger needs to be broken down into more tasks, and the task will probably be spiked. Estimates get smaller in areas that are well understood: these are probably about what engineers would estimate for the story and tasks shown.
See: UserStory, ReleasePlan