Agile chartering / visioning can often be forgotten about. Backlogs, roadmaps and iterations are all the rage but what about getting the vision right. Many will say, that the vision will evolve as the projects moves through the iterations which I heartily disagree with. The first stage in an agile project is defining your product vision. It is an elevator pitch or a quick summary to communicate the goals for the product. The product owner is responsible for knowing about the product, its goals, and its requirements throughout the project and takes responsibility for creating the vision statement, although other people may have input. The vision statement becomes a guiding light, the “what we are trying to achieve” statement that the development team, scrum master, and stakeholders refer to throughout the project.

An Agile Charter has three primary components:

– Vision:The vision defines the “Why” of the project. This is the higher purpose, or the reason for the project’s existence.

– Mission:This is the “What” of the project and it states what will be done in the project to achieve its higher purpose.

– Success Criteria:The success criteria are management tests that describe effects outside of the solution itself.

We want the community that is delivering our product and / or project to understand the why, how, and who of the initiative:-

– Why are we building this product?

– How will we know if it is successful?

– Who is the project community?

By having a Chartering session, we bring the team together to create a common understanding.

Looking at the agile charter, some of the primary things to be answered are:

– Will It Fly:- An important consideration is the economic, technical, operational, and political feasibility of the project. So we ask ourselves:-

• if the system will pay for itself
• if you have the ability to build the system (or to manage the project if you’re outsourcing the effort)
•  if you can keep the system running once it’s built
•   whether you can tolerate the successful delivery of this system

– Laying the Groundwork:- You begin to build your team. You don’t need everybody on the first day, but you do need your key people if available. This can be a bit different from what traditionalists are used to — there is very little “ramp up time” on an agile project because we start doing the work right away. On an agile project, there aren’t weeks or months of modelling, documentation, and reviews to get through. Instead, there are hours or days of it and then you start to work on building working software.

Ideally, agile teams are typically made up of generalising specialists who have one or more specialties (for example, they’re great at both use-case modelling and Java coding), a general knowledge of the software process, and at least a general knowledge of the domain. If you don’t have such people yet, don’t worry as long as you can find people who are willing to work towards becoming a generalising specialist, you should be okay.

If you are interested in taking one of our Agile Courses – click here