Agile development

This is what I gathered from looking at Scrum and Extreme Programming and narrowing down the ideas for our class:

1) Have a “product backlog”, which is a master list (via Google docs or something) of every feature and project-related issue from the user-perspective (not expressed as technical tasks) atomized into stand-alone doable tasks (not interdependent)

2) Nominate a “product owner”, who dedicates themselves to the completion of the project, the elucidation of its requirements, and the only one able to prioritize the product backlog

3) Negotiate as a team (minus the product owner) on the “points” of the highest priority items on the backlog and let the product owner decide whether to change priorities of certain tasks

4) Decide as a team how long to “sprint” for each iteration – for a 10 week project, every 2 weeks is about right

5) Hold a sprint workshop, where the team decides how many points to aim for on the iteration (over iterations, figure out the “velocity” of the team – points completed per iteration), they discuss in detail every item on the backlog that is to be completed this iteration, forming “user stories” to describe the bare bones of all the features to implement this cycle

6) Figure out time constraints for the team for the sprint. Break down all features into sets of tasks to be performed, estimating the time each task will take to complete. Decide on what will constitute being “done” with this iteration, and try to state all tasks or sets of tasks as “deliverables”. Make sure each task takes a day or less to complete. Adjust the goals for this iteration based on time estimates, also including “stretch” tasks if the team delivers earlier than expected

7) Establish a place to work with the team, and a place where the incomplete goals for the sprint (user stories) can be written down, along with (in columns) a TODO task list, an “test cases in progress” list, a "code in progress" list, a “ready to be verified” list, and a “done” list.

8) Hold a 10 minute daily meeting at the same time, where each member briefly reports on what they have achieved since the last meeting, what they will achieve before the next meeting, and anything that may be holding up their progress. Also update an iteration “burndown” chart, which indicates the hours of work, as a team, needed to complete the sprint, compared to original estimates per diem.

9) Get members of the team to work on the same code together, whenever feasible, and when a team member finishes their tasks early, have them work on the tasks of another member. Everyone should be familiar with everyone’s code, ideally.

10) Review every sprint at the end, the burndown chart, the team velocity, discussing what went well, what could be done better, and what will be done differently next time. Continue process through every iteration.