One of the simplest ways to gain agreement on the definition of the problem is to write it down and see if everyone agrees.

Ask the group: What is the problem?

It is very common to rush headlong into defining the solution rather than taking time to first understand the problem. Write down the problem and see if you can get everyone to agree on the definition.

Then ask the group again: What is the problem, really?

Search for root causes or the "problem behind the problem". The real problem is often hiding behind what is perceived as a problem. Don't accept the first statement of a problem. Continue to ask "why?" to find out what the problem "really" is. Sometimes the group can be so focused on an envisioned solution that it is hard to get them to formulate the underlying problem. In such cases, it can be beneficial to explore the benefits of the solution and then try to find the problems being solved by those benefits. You can then explore whether or not those problems are "real" problems in the organization.

• Who are the users of the system?
• Who is the economic buyer for the system?
• Who else will be affected by the output that the system produces?
• Who will evaluate and bless the system when it is delivered and deployed?
• Are there any other internal or external users of the system whose needs must be addressed?
• Who will maintain the new system?
• Is there anyone else?
• Okay, is there anyone else?

What primary features of the system allow the stakeholders to solve their problems? This should be a list of very high-level features.

Once agreed upon by the stakeholders, the vision is communicated clearly to all project team members. When the project starts, XP teams often write up the vision on one of the whiteboards in the team's open workspace so it can easily be seen by all team members. After a short time, the team usually internalizes the vision and no longer needs the reminder.