Engineering Task
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:
- UserStory
- The RJ30 transaction records overtime in hours worked. The employee is to be paid time-and-a-half for overtime worked Monday through Saturday and double time for Sunday. Record time and dollars paid under regular, premium, and double premium. That is, a time-and-a-half hour puts one hour in regular, and one hour in premium, and same for the corresponding dollars. Sunday hours put one in regular and one in double premium.
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.
- EngineeringTask
- Create input transaction definition for RJ30 record. placing record in Hours Raw Input bin. (0.5 day)
- EngineeringTask
- Define new Bins for premium and double premium time and dollars. Add dollars Bins to gross pay composite Bin. (0.25 day)
- EngineeringTask
- Create OvertimeEvaluationStation?, determining for each overtime transaction whether the hours are regular, premium, or double premium. Put corresponding hours in appropriate bins. (0.5 day)
- EngineeringTask
- Create OvertimePayStation?, applying employee pay rate to hours, placing dollars into premium and double premium Bins as required. (Included in 0.5 day for OvertimeEvaluationStation?.)
- EngineeringTask
- Create information notification for any employee reporting overtime over 30 hours. (0.25 day)
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
When should tasks be written relative to acceptance tests? Would a principle of TestFirstDesign not mean that we should be able to talk through showing how the tasks would pass acceptance tests, implying the tests must be written first?
EditText of this page (last edited March 10, 2005)
FindPage by browsing or searching
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006