Product Owners Guide & Team Charter

Our team charter describes a shared understanding of how we best work together. It outlines the essential elements of our communication, and concepts and skills that will focus and guide us.

While this document reflects how we - as thoughtbot - generally work, it should be adapted to every different team we work with to adjust to the specific needs of the project and the team members involved. When you're using it, you can make a copy of this document and review with your team to make the appropriate changes, or create a different one from scratch and use this as a reference.

You can find some templates in these resources: - Team Charter Template | Create a Free Team Charter | Miro - What Is A Team Charter | Free Template | Figma

Project Teams Expectations

• Respect the diversity of teams: We collectively recognize and appreciate individual differences such as race, ethnicity, gender, sexual orientation, body size, religion, ability, age, and socioeconomic status and we expect you to respect and share the same sentiment. We expect everyone to respect the diversity of our team members and be open to feedback in providing a welcoming and successful project experience.
• Be committed: We are dedicated to your project and we expect that you share that focus. Be prepared to commit at least (7) hours per day and up to (28) hours per week working alongside our team. Be clear with us when you're working on the project. Be present in Slack and during Retrospectives, Planning, Status Updates, Weekly Demos, and Syncs.
• Take ownership of feature priority: You'll work together with our team to define and prioritize the work to be done. While we expect to have input and can consult on prioritization tactics and strategy, you have ownership of and responsibility for what is being worked on.
• Run acceptance regularly: We expect clients to run through acceptance on a regular cadence. This is your last chance (they'll have been asking for it along the way too) to provide concrete feedback before the feature is deployed to users. Communicate if something doesn't match what you expected and move it back to Next Up. If the work matches the acceptance criteria, celebrate it!
• Communicate between secondary stakeholders: When there are secondary stakeholders who are not directly impacted by a project, you are the primary conduit of communication between those secondary stakeholders and our team. You should regularly communicate to secondary stakeholders what the product team is working on and why. You should act as a conduit to ensure timely feedback is provided and preferably first-hand.

Team Communication Expectations

• Collaborative: We work collaboratively and are excited to work openly and closely with you and your team. Everyone on the team should understand the problems that we're solving. No knowledge should be siloed.
• Respectful & transparent: Everyone on the team should talk transparently to each other. Hiding concerns or anxiety only makes hard conversations harder. Let's address issues, together, as they come up. Respect regular working hours.
• Clear & Direct: The more clearly we communicate, the faster we'll be able to move on your project. Be direct in feedback. Speak through the lens of problems and your customers. This includes avoiding the use of jargon (e.g. low hanging fruit, circle back, brain dump) and acronyms.
• Friendly & Inclusive: We enjoy helping you solve problems for your customers. Our personality and energy will show through in our communication, and we hope to see yours as well. The backgrounds and experiences of our diverse team vary. To respect these differences please work to be inclusive in your use of language during interactions. For example, avoiding the use of "you guys" to address the full team. We expect you to be open to feedback from the team to continue a valuable experience.

Process Overview

• Work in small releasable features: Together, we'll break down work to the smallest possible features that can be delivered independently. This allows the team to work rapidly collecting feedback early. It allows us to adjust quickly to new priorities and insights.
• Daily Syncs: Either on a video call (for 15-30 minutes) or in Slack. We each give a rundown of our focus today and if we have any blockers.
• Weekly Retrospectives: At the end of each week we'll talk about how that week went. Each person will talk about wins we had as a team, how we feel about the project, and what concerns or new risks they have. We'll then talk about the concerns as a group and discuss action items to resolve those concerns.
• Weekly project planning: As a team, we'll take a look at our project management tool. We'll discuss features that are currently being worked on and what is at the top of "Next Up". During this meeting, we'll develop a team understanding of the next problems that we're trying to solve. Typically, these are at the beginning of the week or following a Retrospective.
• Adaptation: We'll adapt to the needs of the product and team. As global teams, we understand the importance of considering the time zones of each team. We recommend setting up a window for meetings that is within all team members' working hours.

Tools overview

• Project management & messaging (Trello/Notion/Confluence or similar): A place for us to understand what the current prioritized features are, and why they're prioritized that way, and to asynchronously communicate around them.
• Short conversation (Slack): Short form text, question and answer, non-important conversations. Anything longer form should be put into the Project management tool.
• Video conference (Meet/Microsoft Teams/Huddle/Tuple): We use video conferencing regularly for our meetings and pair programming sessions, both scheduled and unscheduled. We can generate ideas, problems, issues, and solutions faster synchronously. After the meeting, any decisions should be added to the Project Management tool and actions should have volunteers/owners, so everyone's aligned on ‘what’s next’.
• Code versioning & management (GitHub): We'll communicate about details of implementation and code on GitHub. We do our work in branches, we'll review code in Pull Requests (PRs) and commit code to a main branch.
• Design collaboration (Figma/FigJam): We'll talk about visual design, user experience, and facilitate asynchronous design feedback, by default we use Figma for this.