Working Agreement Trace‐X - eclipse-tractusx/traceability-foss GitHub Wiki

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 is created by, aligned & discussed within the team at the beginning of the project, and is stored in Confluence so that it is readily available for everyone working on the project.

• We work as one team towards a common goal, vision and clear scope.
• We make sure everyone's voice is heard and listened to.
• Furthermore, we show all team members equal respect.
• We make sure to spread our expertise and skills in the team, so no single person is relied on for one skill.
• Meetings longer than 30 minutes should start 5 minutes later.

• In case we want to distribute urgent information, we tag team members in the teams message or send an individual message via teams chat.
• Our central communication channel in Teams is Trace-X Matrix Chat.
• We add all relevant concepts, product and team-related documentation to the GitHub repos. 
• Hint to GitHub to be included https://github.com/eclipse-tractusx/traceability-foss

• Our core office hours, when we can expect to collaborate via Microsoft Teams, phone or face-to-face are Monday to Friday 9AM - 4PM CE(S)T ,
• We are not expected to answer emails/messages outside working hours, on weekends or when we are on holidays or vacation.
• Meetings which take place in addition to the Scrum ceremonies should happen in the afternoon, the morning should stay free for focused work and/or internal meetings.
• We record meetings when beneficial and agreed by Team members, so that team members who could not attend live can listen later.

• We agree on the linked Definition of Done (DoD) for our user story's and sprints and live by it.
• We agree on the linked Definition of Ready (DoR) & Definition of Done (DoD) for our user story's before they enter the sprint. 
• The DoD is subject to regular inspection and improvement and should be synchronized with all relevant teams.

The Scrum Master 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 and give methodical guidance.
• 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 afterward.
• 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.

• We work together on a Definition of Ready (DoR) on Feature and User Story level and all related issues 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 (DoD)
• We work with the Product Owner if we want to add a new user story / task to the sprint (to avoid scope creep).
• Bullet points are used to define acceptance criteria. ** Gherkin syntax can be added in the description if necessary.

• Team accepts and commits to stories which have the status Refined during planning session. (Exceptional: Critical Stories to deliver value, Security Topics with Critical, High Severity) 
• Team organize and conduct a sprint planning 2 on demand in their responsibility.   

• Visualize and limit WIP (Bad practice)
• Address bottlenecks 
• Minimize handoffs and dependencies 
• Get faster feedback 
• Work on smaller batches
• Reduce queue lengths
• Optimize time "in the zone"
• Remediate legacy policies and practices 

• We follow the git flow branch naming convention for branches by using the following pattern '<chore|feature|fix>/<GitHub_ID>-'
• Hence, the task number is identified, e.g. feature/#123-add-working-agreement
• We merge all code into main branches through PRs
• All PRs are reviewed by one person from the team
• 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.
• Commits according to the following convention: (optional scope):[<Ticket_ID>] (link to Commit-Standards: ConventionalCommits.org) 

1. Create a pull request in GitHub and link it in the story in Jira.
2. Ask a team member to perform the review and assign the ticket accordingly. Assign the PR and the ticket to the team member. Note: reviews should take precedence over starting new stories. Getting some things done is better than starting many things.
3. The reviewer checks the implemented ticket for correctness, completeness and quality and leaves comments in the PR or the ticket if necessary.
4. If the ticket is still in progress and not ready for review, mark the PR as a draft.
5. If changes are necessary, assign the ticket back to the developer and repeat the cycle.
6. To achieve a uniform standard, follow Google's Code Review Developer Guide as described here → Google Code Review