The team for this project is defined as the following:

The project is broken into two-week sprints (or iterations). This length is intended to be long enough to avoid the cost and time implications of each sprint, but short enough to react quickly to change. Every iteration will begin on a Monday and end on the second Friday after. Before the project begins, we must already have a list of requirements and designs from the business. These should not change, but they might, and this process is intended to accommodate that.

The first sprint is known as iteration zero. During iteration zero, anything blocking the team from performing their roles will be dealt with. This may include setting up environments and builds, adding users or licenses to the tools, buying software and hardware, and so on. At the end of this iteration the team will have the following:

During iteration zero, the requirements will be broken into stories in the current tense, such as the following:

The stories will be each given acceptance criteria, which are what is used to define a story as complete. The tester, who should be skilled in edge cases and security holes, will help with these. During this process, other requirements might be discovered. Nonfunctional requirements^[108] should also be considered, since stories may arise from them, too. Example acceptance criteria might be the following:

These stories will be tracked in JIRA and GreenHopper. The stories will also be placed in a prioritized order. No two stories will have the same priority.

We will be using SVN. Our (front-end) folder structure will be as follows:

/
    css/
            build/
                    [Build files]
            i/
                    [CSS imagery]
            [CSS files]
            all-debug.css
    i/
            [Imagery]
    js/
            [JS files]
    [HTML files]
    favicon.ico

All CSS files will be built in the css folder. There can be as many as are needed to keep development easy. Every CSS file will be referenced in all-debug.css in @import statements. Here's an example:

@charset "UTF-8";

@import url(reset.css);
@import url(main.css);

A build script^[109] (in the build directory) will be runnable manually that will parse this file, concatenate all the referenced files (prefixed with the @charset) and save those as all-concat.css. Finally, it will minify that file with YUI Compressor and save it as all.css. In development, the HTML files will point at all-debug.css, but in production they will point at all.css. all-concat.css may be useful for debugging the build process. An SVN hook on the css directory will automatically trigger this build script whenever a CSS file is committed to SVN.

At the beginning of every sprint following iteration zero, at 10am, the team will have a planning meeting, which is facilitated by the project manager. First, the project manager will calculate the resources he has available. We will only need the totals for the server-side and front-end developers. We assume that each member of the team has six hours available to work per day to allow for meetings, replying to emails, and so on. We will take into account planned holidays or days off. We will subtract three hours from this total for the meetings on the first and last day of this iteration. As an example, this would give us totals of:

Next, the highest-priority story will be broken down into tasks. The tasks are for developers, so they need to make sense for the developers. Each task will be marked as a server-side or front-end task, and each will need an estimate in time against it. The estimate should be equally divisible by three hours—if it is less than three hours, multiple tasks may be combined together. Estimates should be rounded up. When estimating the appropriate time for the task, the two appropriate developers should have a conversation until they both agree on the estimate, though other members of the team may contribute to the discussion. The tasks should (like the stories) be in priority order. Here are example tasks:

The project manager should be tallying this against his total resource available. Once this story has been estimated, the remaining resource available is 99 front-end development hours, and 99 server-side development hours. This story and its tasks should now be moved in our tool (GreenHopper) to the iteration. Next, the team will do the same for the highest priority story of those remaining and will continue this process until there are no more hours available. Finally, another story will be estimated and considered to be the stretch for the project, i.e. we may not achieve this, but if we get to it, we will.

After the first Planning Meeting the team can begin development. Every day there will be a stand-up meeting at 10 am, which is facilitated by the project manager. Any member of the team late to this meeting will receive a mark against them. After three marks, that member must buy the entire team donuts at the next meeting! Representatives of the business will be encouraged to attend these meetings, but should not contribute. During the meeting, everyone will gather around a screen showing the current state of the project in JIRA. This will make it immediately clear what everyone is working on. The project manager should highlight any tasks that seem to be taking very long to complete, any developers that have no tasks in progress and isolate anything that is blocking the team from completing any work (as well as creating actions to address these).

Outside of the meetings, the developers should take the highest-priority task from the queue and mark it as in progress. They should do nothing but work on that task until it is complete. When it is complete, they should add a comment letting the tester know how to test that task and then move on to the next available task.

The tester should sign off any task that is complete and mark it as done. If it fails the testing for whatever reason, the tester should add a comment explaining how it failed testing and move it back into the task queue. Only the developer that worked on that task should pick it up.

When all the tasks for a story are marked as done, the tester and project manager should work together to check all the acceptance criteria for that story. If everything is acceptable, the story will be marked as complete.

During the iteration, nothing within the sprint should be changed or added. Whenever possible, however, it is acceptable for new stories to be added to the backlog or for the stories outside of the current sprint to be reprioritized.

On the last day of each sprint are two meetings. The first, the tidy-up meeting that is be facilitated by the project manager, will happen at 3 pm. During this meeting, any incomplete tasks and stories will be moved back into the backlog, and the project manager will work out the sprint velocity. This is the number of hours of estimated work that were actually completed in the previous sprint. Over time, this value can be used to calculate the average number of hours that are actually achieved, which will help with more accurate estimations in future iterations.

The second meeting on the last day of each sprint is the retrospective, which is facilitated by the project manager. The retrospective is intended to be a conversation about how well the iteration went and any problems that occurred and how they could be addressed. It should also be used to recognize any team members who have done well in the previous iteration. If the team has achieved a high velocity, when possible we will take the team to a nearby bar or restaurant and have the meeting there as a reward.

The format of the retrospectives shall be as follows:

The last retrospective of the entire project will be the Project Retrospective. This will take the same form as any other retrospective, but will be based around the entire project rather than only the previous iteration. The project manager may like to present his findings to a wider audience than his team, to recognize them and share any changes to their process they may have implemented that might help the organization as a whole.

Here's a quick recap of the scheduling for the iterations:

The entire process will be repeated until there are no more stories, or the project is deemed complete. At this point, the project is released to an environment for quality assurance (QA), which involves more in-depth testing to ensure the project is ready for release. Then, the project is immediately released to production and is considered to be under warranty for three months.

Finally, the team will move onto the next project, although it must have availability to address any further bugs found for the duration of the warranty period.