Collect User Stories
-Users describe what system needs to do in a few sentences
-When the time comes to implement, the developers go to the customer to receive a detailed description of the requirements face to face.  (Use Cases)  - After release planning?
-Acceptance tests are written for stories to verify correct implementation


Release Planning
-Create a plan to layout the overall project
-The plan is used to create iteration plans for each iteration.
-Goal of release planning is to estimate each user story in terms of ideal programming weeks (including tests)
-Prioritize user stories to decide the order in which they are completed
-A “set” of stories will be created in terms of a release or iteration
-Project Velocity - determine length of project – how many stories can be implemented by a given date (time), or how long a set of stories will take to finish (scope).
Example:
6 iterations, each with 3 user stories, each user story taking 2 weeks to develop, using 3 developers.
Total time for project:  6 * 2 = 12 weeks
Total user stories completed at end of project: 6 * 3 = 18 user stories
6 user stories completed after the first 2 iterations
4 weeks completed after the first 2 iterations
-Iterations are planned in detail just before each iteration begins.
-Things to remember about release planning:  scope, resources, time, quality


Iteration Planning
-Each iteration is 1-3 weeks long.
-Customer selects user stories to implement
-User stories are broken down into programming tasks.  Tasks are in developer’s language; user stories are in customer language.  Tasks will be the detailed plan for each iteration.
-Developers sign up for tasks and estimate how long it will take to develop – a task should take 1-3 days of programming.
-Use Project Velocity again to determine if the iteration is over booked or not, after totaling up the time estimates in programming days of the tasks.  This must not exceed the project velocity from the user stories.  However, the velocity in task days overrides the velocity in story weeks because it is more accurate.
-It’s OK to put user stories off until a later iteration (snow plowing).  Don’t change task and story estimates just because they won’t fit into a planned iteration.
-May need to re-estimate all the stories and re-negotiate the release plan every three to five iterations – that is normal as long as we’re always implementing the most valuable stories first.


Iterative Development
-Divide development schedule into about a dozen iterations of 1-3 weeks.
-Iteration length should be constant throughout project.  It is this constant that makes measuring progress and planning simple and reliable.
-Don’t schedule programming tasks in advance.
-Each iteration needs an iteration planning meeting – easier to stay on top of changing user requirements.
-Track progress during the iteration.  Change estimates early if it looks like all tasks will not get finished.
-Try to create Unit tests first, before the code.
-Unit tests are released in the code repository along with the code they test.
-Code without tests should not be released.
-Unit tests enable collection code ownership.
-However, code ownership is not required if all classes are guarded by unit tests.