- Out of Scope: Sometimes it is important to establish boundaries for a team. Identifying what is not in scope sets limits for the team. Identifying what is out of scope is more important as projects get larger. Programs will almost always need spend time defining which groups should focus on what areas. I often keep this data outside of the charter and post copies (on flip charts) in team rooms.
- Involved Groups: This possible addition identifies other teams, groups and stakeholders that the team will have to interface with to deliver the solution. I generally find this section to be of value for new teams or teams involved with a business solution outside of their normal area of expertise or programs. A quick test for whether the section is needed is to ask whether it can be completed by cutting and pasting the information from somewhere else. If you can complete the involved groups section using a cut and paste from the last charter, the section is not needed.
- Risks: Risks are potential problems that could affect the team’s ability to deliver value or the value of that delivery. While it makes sense to identify and discuss risks when crafting a charter, I do not recommend adding risks to ANY charter. In classic projects, add risks directly to the risk plan, and in Agile projects, add risks directly to the backlog. Having information in multiple locations can require extra time to maintain OR lead to losing information.
- Proposed Release Plan: Developing a release plan helps a team answer questions about when a project will be delivered. Embedding release plans in the charter generates an anchor bias (setting a date or a set of dates in the team’s and stakeholder’s minds), and therefore can be problematic. Recognize that release plans developed early in a project are subject to high levels of variability since significant levels of discovery occur as a project develops.
- Proposed Solution: In most cases I question how the solution can be known before the project begins; therefore, I tend to resist including it in the charter.
- Constraints: Everyone on the team should understand the constraints the team faces. Capturing known constraints as an additional flip chart makes sense and does not add significantly to burden of the process. Constraints can include: fixed deliver dates, budgets, key personnel absences or hardware/software constraints, such as COTS usage requirements.
For another view on what can or can’t be in an Agile charter take a look at the Agile Warrior’s blog. The blog has longer list of items that compose his proposed inception deck/charter.
The decision tree I use for whether to include anything other than the basics in an Agile project charter is:
- Will the team be able to use the information to guide their performance?
If yes, consider including and go to next question.
- Is the data available somewhere else?
If yes, don’t include it. If no, consider including and go to the next question.
- Will I have to replicate the data in another document or tool later?
If no, I will typically include, while if yes I will not include.
My default answer to adding stuff to an Agile charter is no. I require a significant level of convincing to change my mind. The Agile team charter is a tool to help the team focus on achieving a goal and delivering specific value. Anything that does not help achieve that goal does not belong in the charter.