All charters have a goal: to establish a clear and agreed upon definition of success for the team.
If you don’t have a clear definition of your destination when you set sail, any port will do.
Where an Agile charter differs is it singleminded approach to being simple. The Agile charter strives to be the simplest tool needed in order to concentrate the team’s focus by generating a clear statement of what the problem is to be solved and its solution.
While all charters would claim simplicity, some classic project charters can challenge the size of small novels (100k words between content and template) and can take months to write, wordsmith and gain authorizing signatures. Note that this generally occurs after strenuous budgeting. Agile team charters take a different approach and can generally be completed in a single afternoon. An Agile team charter has three attributes that immediately set them into a different universe from classic charters.
- Concise – Agile team charters are time-boxed and constrained. Examples of constraints that I have used include one typed page or four handwritten flip charts (my favorite). Time and size constraints force the team to be very concise.
- Organic – Whenever possible use a flip chart rather than PowerPoint (or presentation software du jour). Flips charts and other organic mechanisms for completing the charter generate engagement; which increases the charter’s value to the team.
- Use language that understandable to the whole team – Do not use legal mumbo jumbo. Reducing the amount of legal mumbo jumbo reduces the time spent on wordsmithing.
Once the team understands the criteria for the charter there are four typical components of an Agile team charter.
- Establish team values and norms – Teams should establish a set of norms or agreements to reduce conflict and promote positive behavior. Norms can include: respecting team members, not talking over others, showing up on time, and living up to commitments. The whole team (Scrum master, product owner and EVERYONE else) brainstorms, discusses, records and then commits to living by the norms. Everyone needs to be able to commit to the norms or the team will struggle with institutionalizing the norms.
- Develop an elevator speech – It is a short summary used to quickly and simply define a project and its value proposition. The elevator speech helps team members understand the project goal and why the project is important. As simple elevator speech outline is:
For [target customer],
who [statement of need or opportunity]
the [project name]
is a [product category]
that [key benefit, compelling reason to buy].
Unlike [primary competitive alternative]
our project [statement of primary differentiation].
- Create a product box – The product box represents the team’s understanding of the central metaphor for the project. Think of a product box as the box that would contain the functionality generated by the project if you could buy it at the store. The team uses the metaphor of designing a box for the software to lock in a common understanding of the project vision. It is critical that the team spend the time needed to draw the box as picture to set the metaphor of the vision deeply into the team’s psyche.
- Components of the product box should include:
- Product Name
- 3 – 4 Key Selling Points or Objectives
- Optional (back of box):
- Product Description
- Features List
- Operating Requirements
- Capture success criteria – the fourth flip chart is success criteria. Success criteria provides the team with a set of goals to use when they need to work through issues or differing expectations. Generating the success criteria as a team ensures the criteria do not represent the point of view of a single person.
An Agile project charter is a tool to focus the team on what needs to be done and why it needs to be done. Because this charter process is relentless focused on simplicity, an Agile team charter can be delivered with far less overhead than a classic project charter.