3.5.1 The Agile Project Charter
On the surface, a charter might not seem like a component of an agile project, however, from a product integration standpoint, it is a key document that is very useful for agile teams. This is because it helps to align the stakeholder expectations to the team’s ability to deliver towards their expectations. Agile project charters can contain many categories of information but the main purpose is to provide clarity so that both the technical and business resources are on the same page. This will result in greater alignments across the organization.
Start with a Collaborative Kickoff Meeting
Begin with a collaborative kickoff for the entire team. This should include the: executive sponsor, product owner or service manager, project manager, and a designated team lead along with as many members of the strategy, discovery, and development teams as are known. This kickoff meeting should accomplish the following high-level goals:
- Align the teams with the business objectives for the project, so there is a firm foundation of understanding moving forward
- Create team energy around the common goal and an understanding of how each team member fits
- Discuss any issues or misunderstandings regarding the project
The kickoff meeting should also lay the groundwork for agile charter activities. It is a collaborative process that includes everyone involved in the success of the project and allows participants to decide what is important, what is useful, and how the team should interact throughout the lifecycle of the project. Agenda items of the kickoff meeting may include:
- Project Vision: Why does the project exist?
- Success Criteria: How will you know when the project is complete and the vision is realized?
- Stakeholders: Who is involved and/or affected by this project?
- Project Risks: What are the top risks of this project?
- Responsibilities: What roles are needed and who is doing what?
- Project Size and Complexity: What is the size and degree of difficulty of this project?
- Product Roadmap: What is the strategic view of where the product is headed?
Once the charter has been drafted, it goes to the Executive Sponsor for approval. Understand that the approved charter should not be filed away and forgotten about. In order for it to be effective, it must be easily accessible to all members of the team. This way, it can be referenced as needed and team members can see if and when updates to the charter are necessary as the project transitions into performing discovery.
Components of an Effective Project Charter
What makes an effective agile project charter? An agile project charter should align the project with the organizational strategy and concentrate the team’s focus. Having the right mindset will help as well, and you should already be thinking in terms of increments or iterations. The agile project charter will be used to generate a clear statement of the problem and its solution and should be:
- Concise. Consistent with the “sufficient” philosophy of using an agile methodology. The charter should have just enough information to provide appropriate decision making. Short and to the point works best.
- Understandable. Separate the legal jargon and other unnecessary information into other documents. This will help save time and makes things easier for those reading it.
- Collaborative. Agile projects are collaborative. The charter should involve the input of the team and organization’s governance (for example input from the Executive Sponsor). The charter should also include what was discussed and agreed upon in the kickoff meeting.
The following table provides a list of charter elements and what the focus of each should be. Note that depending on the project the agile project charter may include additional elements than what is listed here.
| Charter Element | Focus |
|---|---|
| Vision | The “why” of the project. The goal is to have a compelling and clear vision for the effort. |
| Objectives | This is the “What” of the project and it states what will be done in the project to achieve its higher purpose. This should include technical, business, product, and team objectives. |
| Project Size Estimate | An assessment of how big the resources need will be to deliver this service based on assessment of resources and organizational readiness for agile. |
| Project Complexity Estimate | An assessment of how complex delivering this service will be based on assessment of scope and organizational readiness for agile. |
| Scope | Known/assumed customer needs, anticipated functional and non-functional requirements. |
| Organization | Executive/Stakeholder, project team organization chart (especially if there are multiple teams operating at the same time), organizational governance structures. |
| Resources | Space, equipment, people/roles, skillsets and capabilities, collaboration support, and tools. While you may not have names for all the teams that you will form for the project, you should have an idea of what roles you think you will be needed. |
| Approaches | Strategies, methodologies, processes, tools and techniques the team will follow. |
| Success Criteria | What determines the success outside the solution itself? Should be concise, realistic, and directly measurable. |
| Priorities | Ordering, importance, and trade-offs within the project objectives (simulates a high-level product roadmap or release plan) as well as relative to other projects the organization is sponsoring. |
| Product Roadmap | Defines where the product is headed and is tied to the vision and strategic goals. This is a key element that should be included. |
| Assumptions and Constraints | Restrictions, limits, boundaries that apply to the team, process, product, and/or schedule. |
| Risks & Issues | Top risks, known issues, and relevant organizational history that impacts readiness, specific points of uncertainty, and which includes mitigation plans for each. |
| Sign-off | Key stakeholder approval that authorizes the project and other necessary signatures. |
Estimating Project Size
Sizing a project determines how many resources and how much time will be needed to deliver. The size of the project can also be used to determine the extent to which project management practices are formally applied to the project. Determine the project size estimate by using the estimated amount of time the effort will take and its estimated cost. Below is a table that that can be used to assist in ascertaining if your project should be classified as small, medium, or large/mega.
| Project Size Estimate | ||
| Small | Medium | Large/Mega |
|---|---|---|
| Duration: less than 6 months | Duration: 6 months to 1 year | Duration: more than 1 year |
| Cost: less than $500k | Cost: $500k to $2 million | Cost: more than $2 million |
Estimating Project Complexity
Once project size has been estimated it is a good idea to determine the project complexity. Doing this will help to prepare the team and flush out where you may need to focus your attention. Estimates using team experience, similar technology, complexity of stakeholder groups, whether it is greenfield development (a new product/service) or legacy replacement, and any organizational changes needed based on the Agile Readiness Assessment should be taken into consideration.
Keep in mind the experience of your team when using a similar technology. Does the team have no experience, limited experience, or extensive experience? Use a similar approach to gauging the complexity of Stakeholder Groups. Then once you have estimated project complexity be sure to document this information in your charter.
Playbook Contents
Updated: September 22, 2017