In the past, I’ve used a simple format for building a “good enough for now” set of team agreements:
Do’s and Don’ts
Divergent brainstorming:
Converge/Affinity grouping:
I’m looking to up my game a bit.
Curious how others approach having a new, young team create a v1 of Team Agreements.
Andy can you share some example of the team agreements you have done based on the criteria you listed ?
I don’t see anything wrong with what you’re doing today… if it’s “good enough,” great! Especially for a new team, you’ll (hopefully) be inspecting/adapting frequently anyway.
You could try facilitating a conversation with a “focus on/off” chart (described in Esther and Diana’s book) or something similar… I’ve often found this simple exercise is a good enough for a “first draft” of working agreements.
The truth is that a new team might not yet have the knowledge of what their agreements could be! A lightweight, simple exercise is probably best… get something down, inspect & adapt.
You might consider your facilitation and listening skills as the next step to “up your game,” instead of a practice/technique 
Examples
I spent the last few days kicking off new team agreements (not a brand new team but new to each other). We broke them out into the following categories: Environments, Dependencies, Workflow, Communication, Engineering. We also made and effort to phrase them all as “We will…xyz” to make sure they were actionable. For example “We will ‘stop the line’ if there is a defect by marking the story as blocked and notifying the dev pair to drop everything and fix it.”
Was explaining to a team why they needed to add the Andon cord to their working agreement today. Love the actionable context @Colleen
