Jun 04 0 Responses

A Wire Frame for Running an Agile Software Project

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).

Leave a Reply

Your email address will not be published. Please enter your name, email and a comment.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>