| A release plan is an excellent high-level view of how a | | | | spreadsheet or a set of note cards with one task |
| team intends to deliver the most valuable product they | | | | handwritten on each card. In either case, tasks and |
| can. However, a release plan provides only the | | | | stories should be organized so that it's possible to tell |
| high-level view of the product being built. It does not | | | | which tasks go with which stories. |
| provide the short-term, more detailed view that teams | | | | As an alternative to a spreadsheet, note cards can be |
| use to drive the work that occurs within an iteration. | | | | used for step-by-step planning. The cards can be |
| With an iteration plan, a team takes a more focused, | | | | arranged on a table or by taping them to a wall. For |
| detailed look at what will be necessary to implement | | | | collocated teams, my preference is to do planning with |
| completely only those user stories selected for the | | | | note cards. The team may walk out of the planning |
| new iteration. | | | | meeting and immediately type the cards into their |
| An iteration plan is created in a planning meeting. This | | | | software system. |
| meeting should be attended by the product owner, | | | | One of the most significant advantages to using note |
| analysts, programmers, testers, database engineers, | | | | cards during iteration planning is that it allows everyone |
| user iteration designers, and so on. Anyone involved in | | | | to participate in the process. If tasks are being typed in |
| taking a raw idea and turning it into a functional product | | | | a system during the meetings, someone has his fingers |
| should be present. | | | | on a keyboard which causes distractions and a single |
| Tangibly, the results of this plan can be as simple as a | | | | point of failure. |