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 CRC 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.
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.
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
- Create input transaction definition for RJ30 record. placing record in Hours Raw Input bin. (0.5 day)
- Define new Bins for premium and double premium time and dollars. Add dollars Bins to gross pay composite Bin. (0.25 day)
- Create OvertimeEvaluationStation?
, determining for each overtime transaction whether the hours are regular,
premium, or double premium. Put corresponding hours in appropriate bins.
- 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?.)
- Create information notification for any employee reporting overtime over 30 hours. (0.25 day)
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 August 31, 2001)
FindPage by searching (or browse LikePages or take a VisualTour)