One of the most contentious and discussed topics on our team was how to actually run an agile project. After a lot of good debate and maybe a few bad arguments, here is a wire frame of how we run agile software projects.

1. Create a backlog for the project.
   1. Get with stakeholders and ask them what they are looking for in the software.
   2. Write high level user stories with the stakeholders. Format like:
      As a (role) I need (something).
2. Discuss user stories with the development team and assign story points to each card.
   1. Story points are assigned to each story using planning poker.
   2. The numbering system used for story points will be a subset of Fibonacci numbers (1, 2, 3, 5, and 8). These points will be assigned where user stories are relative to each other. A story assigned a 2 is twice as complicated as a 1 and 2/3s as complicated as a 3.
3. At the beginning of each one week iteration, user stories are selected by the development team until the total number of story points equal the team’s velocity.
   1. The stories are detailed out further to add “so that (benefit)” to the story where the card now reads: As a (role) I need (something) so that (benefit).
   2. With this additional information, at any developer’s request, the user story can be assigned a new story point value via planning poker.
   3. All cards with a Fibonacci number of 5, or 8 are broken down into multiple user stories until there is nothing with a value assigned to it that is greater than a 1, 2, or 3.
   4. Add acceptance criteria to each card.
   5. The numbers are added up again, and if the number is less than the velocity of the team, additional user stories are added. If the number is greater than the velocity of the team, user stories are taken away.
4. The cards for an iteration are placed on a board and developers grab one when they begin to work on it.
5. Once complete, the developer places the card on the “Complete” board and grabs the next available card.
6. At the end of each one week iteration, a retrospective is held to discuss lessons learned, any new cards added to the project, and any changes to the team’s velocity. The team will show working software to stakeholders and users when applicable for feedback and sign off.
7. Any new stories that were added to the project are assigned a story point value and added to the backlog board.
8. Plan the next week’s iteration (restart at Step 3).

• Acceptance Criteria – Measurable terms of what must be done for a user story to be acceptable to the stakeholders.
• Backlog – Sometimes called a Product Backlog, the Backlog is a collection of user stories and tasks the development team will work on at some point in the future. Initially, this list consists of all obvious functionality, and it is allowed to grow and change as more is learned about the software.
• Iteration – Sometimes called a Sprint, an iteration is a fixed, specific length of time resulting in a small but complete piece of working software. Multiple iterations combined create a fully integrated product.
• Planning Poker – Planning Poker is a consensus-based estimation technique for estimating. Using this methodology, individual user stories are presented for estimation, and after a period of discussion, each developer chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story being discussed. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. The method has been popularized by Mike Cohn in his book Agile Estimating and Planning, and studies have credited it with less optimistic and more accurate estimations than other methods (K. Molokken-Ostvold and N.C. Haugen)
• Retrospective – A meeting where a development team looks back on the previous iteration so that they can learn from their experience and apply this learning to future projects.
• Stakeholders – Customer representatives from the business who are actively engaged in the project. They prioritize user stories and give real-time feedback throughout iterations.
• Story Points – A measure of magnitude of a paticular user story, and it\’s size relative to the size of other user stories. Story points enable effort to be estimated without trying to estimate how long it will take.
• User Stories – A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.