Working Agreement

A working agreement is a document, or a set of documents that describe how we work together as a team and what our expectations and principles are.

The working agreement created by the team at the beginning of the project and is stored in the repository so that it is readily available for everyone working on the project.

The following are examples of sections and points that can be part of a working agreement, but each team should compose their own, and adjust times, communication channels, branch naming policies etc. to fit their team needs.

General

• We work as one team towards a common goal and clear scope

• We make sure everyone's voice is heard, listened to

• We show all team member's equal respect

• We work as a team to have common expectations for technical delivery that are documented in a Team Manifesto.

• We make sure to spread our expertise and skills in the team, so no single person is relied on for one skill

• All times below are listed in CET

Communication

• We communicate all information relevant to the team through the Project Teams channel

• We add all technical spikes, trade studies, and other technical documentation to the project repository through async design reviews in PRs

Work-life Balance

• Our office hours, when we can expect to collaborate via Microsoft Teams, phone or face-to-face are Monday to Friday 10AM - 5PM

• We are not expected to answer emails past 6PM, on weekends or when we are on holidays or vacation.

• We work in different time zones and respect this, especially when setting up recurring meetings.

• We record meetings when possible, so that team members who could not attend live can listen later.

Quality and not Quantity

• We agree on a Definition of Done for our user stories and sprints and live by it.
• We follow engineering best practices like the Code With Engineering Playbook

Scrum Rhythm

Activity	When	Duration	Who	Accountable	Goal
Project Standup	Tue-Fri 9AM	15 min	Everyone	Process Lead	What has been accomplished, next steps, blockers
Sprint Demo	Monday 9AM	1 hour	Everyone	Dev Lead	Present work done and sign off on user story completion
Sprint Retro	Monday 10AM	1 hour	Everyone	Process Lead	Dev Teams shares learnings and what can be improved
Sprint Planning	Monday 11AM	1 hour	Everyone	PO	Size and plan user stories for the sprint
Task Creation	After Sprint Planning	-	Dev Team	Dev Lead	Create tasks to clarify and determine velocity
Backlog refinement	Wednesday 2PM	1 hour	Dev Lead, PO	PO	Prepare for next sprint and ensure that stories are ready for next sprint.

Process Lead

The Process Lead is responsible for leading any scrum or agile practices to enable the project to move forward.

• Facilitate standup meetings and hold team accountable for attendance and participation.

• Keep the meeting moving as described in the Project Standup page.
• Make sure all action items are documented and ensure each has an owner and a due date and tracks the open issues.

• Notes as needed after planning / stand-ups.

• Make sure that items are moved to the parking lot and ensure follow-up afterwards.

• Maintain a location showing team’s work and status and removing impediments that are blocking the team.

• Hold the team accountable for results in a supportive fashion.

• Make sure that project and program documentation are up-to-date.

• Guarantee the tracking/following up on action items from retrospectives (iteration and release planning) and from daily standup meetings.

• Facilitate the sprint retrospective.

• Coach Product Owner and the team in the process, as needed.

Backlog Management

• We work together on a Definition of Ready and all user stories assigned to a sprint need to follow this
• We communicate what we are working on through the board

• We assign ourselves a task when we are ready to work on it (not before) and move it to active

• We capture any work we do related to the project in a user story/task

• We close our tasks/user stories only when they are done (as described in the Definition of Done)
• We work with the PM if we want to add a new user story to the sprint

• If we add new tasks to the board, we make sure it matches the acceptance criteria of the user story (to avoid scope creep). If it doesn't match the acceptance criteria we should discuss with the PM to see if we need a new user story for the task or if we should adjust the acceptance criteria.

Code Management

• We follow the git flow branch naming convention for branches and identify the task number e.g. feature/123-add-working-agreement

• We merge all code into main branches through PRs

• All PRs are reviewed by one person from [Customer/Partner Name] and one from Microsoft (for knowledge transfer and to ensure code and security standards are met)

• We always review existing PRs before starting work on a new task

• We look through open PRs at the end of stand-up to make sure all PRs have reviewers.

• We treat documentation as code and apply the same standards to Markdown as code