Charters in Agile can be used to help a team bond and focus. As efforts scale up to require teams of teams, the charter also is useful as a communication vehicle. The four categories of information are typically included in Agile Charters are:
Each category addresses different concepts that are important to help a team or a team-of-teams in a scaled effort to act in coordinated manner. We complete our tour of the four basic topics of Agile Charters by reviewing the possible topic areas with the components that can be used to address constraints.
Summarized below are the most common components used to address constraints. A quick definition is included for each component and a recommendation whether the component should be used for either a team or scaled Agile charter. Yes means the component should typically be used, meh is an unenthusiastic maybe and no means don’t.
Components in this category identify resources, tools, people, money and other assets available to the effort and the boundaries on the use of these items. The definition of assets and the limitations of those assets are inextricably linked. Understanding the true constraints a team faces makes planning and delivering easier!
- Out of Scope identifies the functions, needs or requirements that will not be addressed by the effort.
- Scaled Charter Recommendation: Meh – Identifying what is out of scope is typically needed when product ownership isn’t a strong practice within the organization. Efforts with weak product owners are often susceptible to scope creep.
- Team Charter Recommendation: Meh – A section for out of scope really is only needed when the product owner doesn’t understand their role and does not own the backlog.
- Constraints describe boundaries within which the effort will operate. Constraints can include people, resources, budget, calendar and technology.
- Scaled Charter Recommendation: Yes – Scaled efforts typically need to establish and communicate a common set of expectations.
- Team Charter Recommendation: Meh or No – In stable environments, common constraints are generally well understood do not need to be documented.
- Assumptions are ideas, concepts or presumptions that are accepted as true without proof. In software development, assumptions are generally shortcuts taken based on perception of the development and business environment. Once upon a time a wise boss informed be the word assume could be broken down to the words ass, u and me. His point was that making unrecognized assumptions would make an ass out of us all.
- Scaled Charter Recommendation: Yes – In scaled efforts it is easy for a wide range of assumptions to be made and then not shared. Documenting those assumptions are critical for ensuring they are shared. Capturing and recognizing assumptions can be the difference in delivering value or delivering…crap.
- Team Charter Recommendation: Yes or Meh – In stable environments and with teams that have worked together for at least a few months, common assumptions are generally well understood do not need to be documented. When the environment or team change consider documenting assumptions.
- Resources can be many things ranging from hardware, office space to people. Agile projects have just as many resource constraints as any other type of project. Addressing any constraint begins with
- Scaled Charter Recommendation: Yes – Documenting resource constraints allows wide groups of people to be cognizant of constraints. Note: Resource constraints that translate to risks should be treated as risks (see below).
- Team Charter Recommendation: Meh – Common resource constraints such as the size of the team are givens and should be reflected in the planning activities rather than in a document. Only document resource constraints IF they are out of the ordinary. A simple documentation technique is to write the constraint on flip chart and post it on the wall.
- Risks are the potential of something going wrong that will reduce the value an effort can deliver. Agile efforts have a different risk profile than classic projects however the risks that exist must be recognized. Rather than putting risks in a charter they should be incorporated into the backlog or into the definition of done.
- Scaled Charter Recommendation: No
- Team Charter Recommendation: No
- Involved Groups define the interface between the effort and external groups. Documenting involved groups can be helpful to ensure the correct conversations and handoffs occur.
- Scaled Charter Recommendation: Yes – As Agile efforts are scaled up the number of interfaces between groups inside (and potentially outside) of the effort increase.
- Team Charter Recommendation: No – The only reason for documenting involved groups at a team level is if something very out of the ordinary is going on.
Use the components that make sense for your effort. Almost no Agile project will need each component. As mentioned in team-level charters, start with the minimum subset of norms, elevator speech, product box and success criteria. For a scaled efforts, evaluate the sections we identified as Yes in each of the four sections. A charter for a team or a scaled effort is not anti-Agile if the information captured real needs and facilitate delivery of value.