Cargo ships on Lake Erie

The bigger the ships, the more barnacles.

As we noted in Agile Charter Barnacles, the basic Agile project charter is brief and to the point. However, there is a natural tendency to add components back from classic charters.  The charter is a tool for the team, therefore the team needs to find the components that add value to how they work.  When these components add value, adding these sections makes sense.  A number of readers of the Software Process and Measurement blog have asked about whether adding specific charter sections make sense in an Agile project or whether there are other techniques to address their needs. Here are my answers:

  1. Roles:  Classic charters typically include a section that describes the roles that team members will play on the project team.  Agile teams are self-organizing, and roles change to ensure that the team can deliver the work they commit.  In large Agile programs, identifying areas of focus for teams is often valuable to help direct communication. Projects that are using classic project management methods with a smattering of Agile techniques will need to document roles.  However, at the team level, documenting regimented roles does not make sense for most Agile projects.
  2. Resources: Resources represent the assets that a team can draw from to deliver value and function effectively.  Resources can range from physical space to knowledge capital.  In general I only recommend identifying and documenting resources when they are outside of the norm and could be easily overlooked.  For example, I was once asked if was important to identify and document that the project team was going to use a new team room.  Since the team would tend not to forget where they worked, I suggested that they probably did not need to document the room as a resource.  An Agile team charter is a team-level tool, not an external communication vehicle.
  3. Context: The context for the project can be helpful for the team(s) involved in developing and delivering a solution.  In a very real sense the product owner is physical manifestation of context.  In small projects, the access of the product owner will generally suffice as a means to share context. In larger projects or programs with broad or complicated business objectives, capturing context is important.  I generally recommend in cases where capturing the narrative context is important that a separate document (this is generally not flip chart territory) is generated and that the product owner spearheads its creation.
  4. Milestones and Delivery Cadence: The Agile release plan documents the strategy that the team intends to use for delivering the project.  Release plans will identify whether functionality will be delivered to production on continuous basis, at the end of every sprint or after a number of sprints as a release. Identify the strategy the team intends to follow in the charter if it outside of the normal pattern the team follows. The release plan itself should be documented and maintained separately from the Agile team charter.
  5. Assumptions:  Assumptions are defined as things that accepted as true or certain to happen without proof.  Teams should always reflect on what they accept or believe is true that is not supported by evidence.  Assumptions that are outside of the norm need to be treated as potential blockers, captured and pursued by scrum master/coach to verify or treated as risks (documented as user stories and included in the backlog).

To add components to the Agile team charter or not to add components to the Agile team charter, that is the question. Since the Agile team charter is a tool that helps focus and guide the project teams — then the answer is add a component only if it adds value to the team.