When beginning a new project of any appreciable size and scope, I always start with a project charter to define the project vision, the business case for the product, basic scope and critical success factors.  I also use the project charter to clearly define, to the stakeholders of the project, the agile processes that will be employed to manage project development.  If you've gotten to the project charter, you've surely already talked to your client about the wondrous benefits of agile development; the project charter is a great place to clarify these processes and get their buy-in.  Below is an example of the language I use to convey the agile processes and establish an agreement for management of requirements and communications.  With this in place in the project charter, the client is made plainly aware of agile methodologies and enabled to set expectations, accordingly.  You'll also find it goes a long way for instilling more confidence in them believing that you're going to successfully deliver exactly what they want.

DISCLAIMER:  I am certainly no lawyer and do not imply that what follows is legally binding or enough to keep you out of trouble on your project in any way, shape or form. ;)  If you're getting your client agreement documentation together for the first time, I would highly recommend running them by a lawyer before getting them signed by a client.  I would also recommend getting a master service agreement in place that defines all the "whereby," "thereby," and "herein" clauses that lawyers love to write!

Project Management Processes 

Process

To provide more immediate feedback, to better indicate progress and to aptly adjust to changing requirements, agile development techniques will be employed to deliver <project name> over a series of two-week iterative cycles.  Each successive iteration will focus on the next highest business priorities factoring in:

• The financial value of having the features
• The cost of developing the new features
• The amount of impact on the rest of the project by the features
• The amount of risk removed by developing the features

Through iterative cycles, the highest priority is to satisfy stakeholder needs through early and continuous delivery of valuable software.  Working software will be emphasized over verbose requirements documentation to measure progress and elicit feedback.  Business needs will be realized as software by organizing the project requirements as follows.

Releases

To provide more accurate estimates and to facilitate deploying features over a number of iterative cycles, project requirements will be encapsulated into a number of releases.  Each release is expected to take <release length> to complete from inception to deployment.  Requirement “themes” will encapsulate the high-level goals for each release.  It is anticipated that <project name> will be delivered over the course of <#> releases.  The following releases are listed in priority order but may be reordered based on the changing needs of project stakeholders; the bullet points are the themes within each release:

1. <Short scope description of release 1>
• <Description of theme 1>
• <Description of theme 2>
2. <Short scope description of release 2>
• etc.

Each release will be broken down into successive two-week iterations.  Each iteration will end on a Thursday and begin on the next day, Friday.  The end-iteration Thursday will be spent reviewing progress of the previous iteration and providing feedback.  The next day, Friday, will be spent planning for the next iteration and prioritizing features.  This cycle will be repeated every two weeks.

It is anticipated that the first two-week iteration will be spent refining scope, providing more accurate estimates and developing the proof-of-concepts for higher risk items.

User Stories & Tasks

Each iteration will be broken down into a number of “user stories.”  Each user story represents a chunk of functionality that can typically be delivered in one to four days.  User stories will be the primary means of encapsulating functional requirements and for establishing a basis for estimates.  Each user story will contain:

• User story description:  The description expresses what piece of functionality will be delivered from the user’s perspective.  An example would be “As a user, I can search for specific orders with a date range to create a custom report.”
• Priority:  The priority of each user story is set to provide guidance for development; the highest priority user stories are typically addressed first.  The priority of a user story may be one of the following:
• "Must have" – Necessary for the system to be viable
• "Want to have" – Not absolutely necessary, but valuable
• "Nice to have" – Not necessary for success of project.  It will be emphasized that at least 20% of the features defined will be declared as nice-to-haves.  This will give application stakeholders the opportunity to drop lower priority user stories in favor of higher priority changes that are discovered throughout the project without adversely affecting the schedule and budget.
• Risk:  Each user story will be given a risk of “High,” “Medium” or “Low.”  This risk assessment will have two impacts:
• High risk user stories that are must-haves or nice-to-haves should be split into lower risk user stories or should be given attention earlier in the project to mitigate the risk with proof-of-concepts.
• High risk user stories that are nice-to-haves should be considered to be dropped from the project.
• Estimate:  Each user story will be given an estimate in “points.”  The number of points a user story is given is relative to the points of other user stories.  For example, a simple user story might be given 3 points.  Another user story that is approximately twice the level of effort as the first would be given 5 points.  As iterations progress, it will become apparent how many points can be completed in a given iteration; consequently, we’ll continually have a good level of confidence for stating how long the rest of the project will take based on the number of user story points that are remaining.  (Themes represent very large user stories which are typically given point values in the range of 20-100.  When release planning begins, themes included within that release are broken down into smaller user stories usually less than or equal to 8 points each to improve estimating accuracy.)

Communications

Requirements Tracking

To better facilitate communications, and to assist with project visibility, the online tool Mingle will be utilized to track releases, themes, user stories and daily tasks.  Mingle includes a number of easy to use reporting tool and provides good real-time views of project progress.  More information concerning Mingle can be found at http://studios.thoughtworks.com/mingle-project-intelligence.

Daily Meetings

Daily meetings will be held by developers on the project.  Daily progress will then be reflected in Mingle for review by project stakeholders.  The daily meeting will be held to assess work done the previous day, make goals for the current day and to discuss any obstacles that may be impeding progress.

Iteration Review

It is imperative that project development receives regular feedback from project stakeholders.  To help facilitate this, it is recommended that <name of Product Owner> and the development team meet for face-to-face discussions to assess progress, accept change requests and provide prioritization of next requirements to be developed.  The most appropriate meeting days would be the Thursday and/or Friday representing the end of the current iteration and the beginning of the next development iteration, respectively.

Taking up just a couple pages in a project charter, the above clearly defines how agile methodologies will be employed during project development and sets clear expectations for the client...and they love those.  You could certainly extend this for more specific agile processes or carry it into the maintenance stages of development, but keeping it simple in the project charter is usually the most effective approach to take.  Keeping it simple also gives you more room to adjust the project management processes throughout the project life-cycle to account for lessons learned and process improvement.

Billy McCafferty