Team Agreement is a Team constitution, so draft it carefully and follow it religiously
What is a Team Agreement?
To better understand the concept, let’s look back at the waterfall project delivery model. In the waterfall methodology, teams are formed to deliver a particular software project, and after the project, the delivery team members are dispersed into other projects. Fast forward to today, where projects are delivered in an Agile framework, with a team formed to support a set of applications and features and deliver enhancements. Most importantly, team members may stay in the same team for a longer time. The universal fact is that every person is different and unique, and the same applies to the team. They’re going to have their unique style of development, their habit of delivering a task. However, for a team to be successful, every team member should work together, coordinate, communicate, and adhere to a team-level statement that they have agreed to follow. This team-level statement that outlines team-level standards is called Team Agreement.
Why Team Agreement is important?
To understand its importance, let’s take a few examples:
Imagine a case where every engineer is using their code styling format when programming, an application is going to have multiple code styling formats, and regular conflicts to change code styling before review.
Another case where the team does not have a definition of done would result in a chaotic story demo and confusion for the product owner about whether or not to accept a story. I could go on with several more examples, but I guess you got my point. Team Agreement could help to reduce team friction, promote a standard work process, and help new team members to understand the team’s way of working.
Crafting Team Agreement
As with any other process document no team can get team agreement perfect on their first attempt, hence it’s going to be a continuous process, and it should be visited regularly (at least quarterly) to make sure team agreement still makes sense. A few tips to craft the best team agreement:
Never assume quite obvious things, as not everyone has the same level of understanding. Something that could be quite obvious to someone may not be intuitive to others.
Consider team agreement as the constitution of a team, so draft it carefully and follow it religiously
The Tech Lead, Product Owner, or Scrum Master can take the lead in drafting the team agreement; however, every team member should contribute because it is for the complete team.
Below is a general format:
1. Daily Standup
a. What time?
b. What will be discussed?
c. How to utilize remaining time?
2. Story Refinement
a. Story template to use?
b. Definition of ready?
3. Feature Refinement
a. Feature template to use?
b. Definition of feature ready?
4. Sprint Planning
a. Team velocity?
5. Sprint Retrospective
a. Who will run the retro?
6. Sprint Demo/Review
a. Definition of Done?
7. Development Branching Strategy
a. Git or GitHub or trunk-based?
8. Pull Request (PR) Agreement
a. Use a PR template?
9. Coding Agreement
a. Use proper linting/styling?
Team Agreement Sample
Here you go, a sample team agreement.
1. Standup
- Daily at 8:00-8:30 AM
- First 15 mins for update, next 15 mins for blocker, demo
- Start with the update, task for today, and blocker
2. Story Refinement
- Weekly on Monday at 10:00 AM
- Use the story template to create a new story
- Definition of ready
- Story is estimated
- No open question
- All dependencies and risks are resolved
- Acceptance criteria are well defined
3. Feature Refinement
- Biweekly on Tuesday at 10:00 AM
- Definition of feature ready
- Feature acceptance criteria are well defined
- No open question
- All dependencies and risks are resolved
4. Sprint Planning
- Consider the average team velocity to take the total story points
- Account for any upcoming holidays
5. Sprint Retrospective
- Who will run the retro
- Everyone should contribute
- Look at the last retro action items
- Every action item has an owner
6. Sprint Demo/Review
- Definition of Done
- Evidence is attached as proof for story completion
- Story is marked as completed
7. Development Branching Strategy
- Git or GitHub or trunk-based
8. Pull Request (PR) Agreement
- Use a PR template
- Follow the naming convention when opening a PR
- Address all review comments
9. Coding Agreement
- Use proper linting/styling
Conclusion
A team agreement is not a rigid rulebook; it is a living document that evolves with the team.
As teams grow, new members join, and ways of working change, the agreement should be revisited regularly and refined during retrospectives. The goal is not to enforce process for the sake of process, but to create clarity around how the team collaborates and delivers software together.
Even a simple agreement around standups, pull requests, coding standards, and branching strategy can significantly reduce friction and improve team productivity.
If your team does not already have a working agreement, consider starting small. Draft a few shared guidelines, discuss them openly with the team, and iterate over time.
Often, the biggest improvement in software delivery does not come from new tools; it comes from alignment on how the team works together
If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind to leave any comments or ask for any corrections.
Top comments (0)