To your last point, writing it down is sometimes necessary to aid agreement and communication. If you can achieve those objectives without paper - go for it. I fully agree that the process is more important than the output and simplicity is key. On the other hand, a team that works together for a long time may need a way to store their thoughts about why they exist to keep them focused. The last few bullet points are really planning steps and should eventually be integrated into whatever structure you use day-to-day whether it is a card system, spreadsheet or other work management application.

Do these need to approached in a formal process with a charter written on a document… probably not. (who’s going to update/read the document later?) And, shouldn’t the sponsor be part of that process?

Also, one thing I would suggest be added to this list (at least more explicitly) is the team’s agreements to each other. How will they handle failed tests or failed builds? Are they committed to pair programming or TDD? Are customer demo’s done at sprint review or throughout the iteration? Do standing meetings start on time or when everyone is present? Without these agreements, the team won’t be in sync with one another.

Good post… I’m supportive of the concept and need, just not the full formality. I only like writing documents when I know someone will read them later.