I am a big fan of Agile methodology, but I use tools from waterfall project management with the methodology, such as project charters. It makes sense to define pieces of a project down to specific items and define them as a user story. I like the Agile ceremonies such as scrum, sprint planning, backlog grooming, demos and retrospectives. The structure of the operating rhythm combined with the flexibility of the small defined user stories, makes a successful approach to software development. I do not agree that defining an Agile project should come into play until a well defined problem statement and project charter are defined. If the team can't align under a specific charter, then there is a high probability that the project won't be successful.
A well defined project starts with a well defined problem statement. Sometimes, the problem statement is a large level problem, such as improve cash flow. In these cases, the problem needs to be scoped down to an actionable level. For example, if the goal is to improve cash flow then determine what lever of cash is the most impactful and focus on that. Maybe your business has a tough time collecting revenue from customers, so it would be reasonable to start there. If data is available, use it to quantify the most important scope to work.
Once a problem is well defined, what are the critical to quality (CTQ) characteristics of the project? These are the top 3-5 requirements that are the most important. If none of these are true after the project is complete, then the project is not considered successful. These are not the detailed requirements, as those will be vetted in the user story and scrum processes. For the problem statement above, example CTQs may be as follows:
Visibility into the accounts receivable data by customer
Automated alert for days unpaid > 10 days
The solution needs to be hosted inside the firewall or in a Government cloud to meet ITAR
The next item to consider in the project charter is the benefits of the project. Benefits should include the primary financial metrics, but also the impact on the organization as well. In the case of accounts receivable, the benefit is more timely cash collection from customers, but it is also an improvement of communication between finance, sales and the Profit and Loss leader.
Another highly important piece of a project charter includes the project team. The team is the business champion as well as all people required to make the project successful. What is the communication plan amongst the team? Consider how the stakeholders should interface with the scrum development team and define these roles up front.
One item that belongs on a project charter that often gets overlooked is the addition of a risk analysis. It's important to identify any project risks or potential issues that could impact the projects. Don't let these risks live as shadows in the corner, or items that get whispered about in the break room after the meeting adjourns. Get these items on paper, let them be known so you can work together as a team to mitigate the risks. One way to pull these risks out of people is to ask, "What could cause this project to fail?"
The final item that I like to put on the project charter is a high level milestone schedule. It may be controversial to the Agile process, but there should be some target dates in mind to keep the team aligned on expectations. If a milestone will take a month, then put it on a brief timeline.
In summary, before launching into the Agile process, make sure that all stakeholders agree on the defined project charter. This document can be used to create alignment amongst the team as well as represent the final decisions before launching the project.