Team Charter and Norms

A Team Charter in the context of a software engineering team is a team document that lists their goals, objectives, scope of work, and rules of engagement. This is a working agreement between all members of the team on how the team collaborates and communicates, and how they hold each other accountable while working towards common goals.


Here are some areas I like to cover in a team’s Team Charter. This can be at the team level or the organization level. 

  • Goals: This is a one-line sentence that explains the goal(s) of this team. 

  • Objectives: This section links to the team or organization's objectives, key performance indicators (KPI) or Objectives and Key Results (OKR) which can be quarterly, semi-annual or annual.

  • Organization Chart and Team Structure: This helps people know where they are in the organization and what teams and people they interact with regularly.

  • Helpful Resources: This links to the team’s Request For Comment or Technical Design Documents, Slack channels, meeting notes and self-service meeting invites.

  • Team Norms: This documents how the team works together, what processes they use for meetings, giving feedback and triage.

  • Dashboards: This shows metrics that the team tracks on a regular basis.

  • Time off calendar: This links to the team’s time off calendar or shows an embedded team calendar.


The Team Charter essentially is the source of truth for anyone onboarding on the team and is a living document for recording how the team works together. 

✍🏽 Documenting a Team Charter

Most project management tools such as Confluence offer templates for a Team Charter like this Homepage. When I join a new team, I usually start at their Home page or onboarding docs and update it as I go. Here’s how I go about it if the team does not have a Home page or Team Charter:

  • Start with the goal(s) of the team. 

  • Use a pre-existing template for a Team Charter and fill out everything I learn as I go. Add new sections as needed. 

  • If the team has never run a Team Norms setting meeting and there is a need for one, then facilitate the meeting. This is usually recognizable if features are not delivered on time or there is no clear ownership or accountability on different scopes of work.

  • Send a new collaborative Team Norms document out beforehand with clear instructions to the team on how and when they need to fill this document by. 

  • Meet once or twice to go through the working document above and record decisions for every single section. 

  • Update the relevant sections in the Team Charter document above.

  • Encourage everyone on the team including new hires to update the Team Charter as needed and to drop a note in Slack about changes made. 

🗣️ Team Norms - Topics of Discussion

Any of the following people in the role of Engineering Manager, Program Manager, Scrum Facilitator or Team Lead can facilitate a Team Norms setting meeting. This meeting can take place over 1 to 2 hour-long sessions. High-level outcomes are recorded in the Team Charter. It also makes sense to meet every 6 months or so when the team processes start breaking down. Here are some discussion topics for the team norm settings meeting:

Stand-up 

  • Preferred daily stand-up time and length keeping time zones in mind

  • Preferred stand-up content - yesterday, today, blockers

  • Preferred stand-up days 

  • Preference for Slack stand-up updates

Tickets

  • Bug, Sub-task, Task, Story, Epic, Epic of Epics

  • Ownership of tickets - Product, Engineering, Program Managers

Backlog Grooming / Refinement

  • Definition of Done for different ticket types

  • Ticket/Issue template

  • Story pointing 

  • Acceptance criteria

  • Creating tickets

Sprint Planning

  • Capacity Planning

  • Time off calendar

  • Project swimlanes - Ready for development, In progress, In Review, In QA, Done

  • Acceptance Criteria

Sprint Retrospective

  • Tools used

  • Sad/Mad/Glad or Kudos/What Went Well/What could do better/Action Items

  • Action items

Pull Requests 

  • Pull Request Template

  • Branch names

  • Branching norms 

  • How we do Pull Request reviews

Meeting times

  • How often to meet

  • When to meet

  • When to use Slack vs meetings

  • Creating “meeting” and “making” blocks of time on calendar

Paid Time Off / Vacation 

  • Where to update - Slack, Time off calendar, Email

  • Coverage Plan documents for longer time off

On-call/Triage

  • Triage Runbooks

  • On-call rotation

Request for Comments (RFC)

  • RFC template

  • Getting started with an RFC

Feedback

  • How we give feedback individually

  • Preference for private or public feedback

  • Preference for Slack or video call for feedback

Interviews

  • Agree on technical and behavioral questions 

  • Rubrics

  • Feedback

Product/Design

  • Involve Product Owner/Designer in Team Norms settings or share document

✅ Measuring success

It can be hard to quantify why teams should write about how they work together but I find this to be a good exercise that helps teams and their leaders keep their eye on the following:

  • Ease of onboarding new members on the team

  • Noting down team process changes and relevant action items from retrospectives in the team charter

  • Ease of working together with each other once norms are established

  • Delivering high-quality projects on time


Photo by Nick Fewings on Unsplash.
Emojis from emojipedia.org

Comments

Post a Comment

Popular posts from this blog

Recap of Android Summit 2017

I recently attended and spoke at Android Summit , an Android conference organized by the folks at Capital One. Special shoutout to Jared A Sheehan, Michael Jones and the entire organizing committee for running a fabulous event which raised $6000 for Women who Code. All speakers received a Phillips Hue Starter Kit as a speaker gift which I've used to toggle and dim my living room lights via Amazon Echo. So much fun! I had a prior commitment and could only attend Day 1 but here are my highlights. Process & Workflow A common theme on Day 1 was process and workflow talks which tied in beautifully with Kelly Shuster 's keynote. Kelly is an excellent story teller. In her keynote, she connected a story of communication from her theatre background to how developers, designers and testers need to work together to reduce boiler plate conversations when designing and developing apps. I gave a similar talk earlier this year at  Chicago Roboto  with my co-worker and designer  J
Read more

Team Charter and Norms: Working together

Image
In my previous blog post , I wrote about setting up a Team Charter and Team Norms on a team. In this post, I elaborate on some of the rules of engagement that teams I have worked on have generally used. Most software development teams that I have worked on have used some sort of Agile practices like the Scrum framework where cross-functional teams use iterative and incremental processes to improve their software delivery process. I have always used Agile in a way that works best for my team and the company’s culture at that time.  🧱 Team Structure I have had to occasionally run Scrum meetings as an Engineering leader since I have been on teams without dedicated Scrum Facilitators or Product Owners. Each Scrum team usually includes an Engineering Manager, Scrum Facilitator or Project Manager, Product Manager and Developers. In the absence of dedicated Project Managers or if there is leadership interest on the team, I make the Scrum lead role rotational so that every person on the team
Read more

Chicago Roboto 2018 Recap + First Keynote!

Chicago Roboto was back again this year as a single track conference and there were a lot of excellent talks.  Last year I gave a talk with my co-worker and product designer extraordinaire Jess Moon about design and development workflows and this year I was back again but as a Keynote speaker. Keynote Giving a keynote was a stretch goal I set for myself in 2018 and I managed to achieve it early thanks to the Chicago Roboto review committee. The topic I chose was being an Android Advocate who brings teams and communities together. I will be writing a follow up blog post about my keynote process soon but before that, a quick shout out to Corey Latislaw and my coworkers at Warner Bros. Digital Labs who took a look at my first and second drafts and listened to all my half-baked thoughts and ideas. Achievement unlocked 🎉🎉🎉 - Gave my first keynote @chicagoroboto #chicagoroboto Slides with resources available at https://t.co/OJVbZa3Akj — Yash Prabhu (@yashvprabhu)
Read more