• Implement year at a glance widget.

• Implement data model and report.

• Acceptance test: validate payments in months for members.

CloseChase • Compare rates and services at local banks.

• Open new account.

• Move automatic payments (FedEx, EarthLink)

• After last check clears, transfer remaining funds.

• Acceptance test: verify account is closed and automatic payments working.

For reasons of simplicity, I write the tasks directly on the bottom of the story cards. This keeps the motivation for the work (the story) and the list of work items on one piece of paper. This helps me stay focused on the trees without getting lost in the forest.

Alternatively, you might create separate task cards, one for each work item. This allows you to divide up the work for an individual story among several programmers. If you tend towards larger, multi-week stories, task cards are probably the way to go.

5.2 The Meeting

Iteration planning involves the entire team. Somebody reads the stories aloud, and everybody contributes to identifying the tasks, which are written on whiteboards or flip charts for all to see. Another person writes the tasks down on the cards once everyone agrees they are correct.

The meeting is a time for group design discussions. It isn’t always obvious what tasks are required to implement a story. While ad hoc design discussions pop up during programming, iteration planning is a time for the whole team to discuss the system’s implementation. You might realize that a global refactorings need scheduling. This may add dependencies and possibly a new story for the customer to prioritize.

After all the tasks are listed on the board, people commit to implementing them. Individuals take the cards and estimate the tasks they are planning to implement. As with stories, estimate in ideal programming days. Everybody’s ideal timescale is different, don’t expect the task and story estimates to add up.

If a task is difficult to estimate, ask for help. Others may have a better feeling for the problem and/or implementation. Sometimes a task is too



	• Implement year at a glance widget. • Implement data model and report. • Acceptance test: validate payments in months for members. CloseChase • Compare rates and services at local banks. • Open new account. • Move automatic payments (FedEx, EarthLink) • After last check clears, transfer remaining funds. • Acceptance test: verify account is closed and automatic payments working. For reasons of simplicity, I write the tasks directly on the bottom of the story cards. This keeps the motivation for the work (the story) and the list of work items on one piece of paper. This helps me stay focused on the trees without getting lost in the forest. Alternatively, you might create separate task cards, one for each work item. This allows you to divide up the work for an individual story among several programmers. If you tend towards larger, multi-week stories, task cards are probably the way to go. 5.2 The Meeting Iteration planning involves the entire team. Somebody reads the stories aloud, and everybody contributes to identifying the tasks, which are written on whiteboards or flip charts for all to see. Another person writes the tasks down on the cards once everyone agrees they are correct. The meeting is a time for group design discussions. It isn’t always obvious what tasks are required to implement a story. While ad hoc design discussions pop up during programming, iteration planning is a time for the whole team to discuss the system’s implementation. You might realize that a global refactorings need scheduling. This may add dependencies and possibly a new story for the customer to prioritize. After all the tasks are listed on the board, people commit to implementing them. Individuals take the cards and estimate the tasks they are planning to implement. As with stories, estimate in ideal programming days. Everybody’s ideal timescale is different, don’t expect the task and story estimates to add up. If a task is difficult to estimate, ask for help. Others may have a better feeling for the problem and/or implementation. Sometimes a task is too Copyright © 2004 Robert Nagler 34 All rights reserved nagler@extremeperl.org