Creation and Changing

The Team Agreement is created and maintained by the team in a way of mutual agreement.

• Everyone can propose a new rule, modification to a existing rule or removal of a rule, and show concerns to other's proposal.
• A rule can be created, modified or removed only if it's agreed by all team members.

Purpose of Team Agreement

The team agreement is to increase communication/collaboration efficiency, reduce communication cost and errors/misunderstandings, and ultimately bring high performance of team working.

Content of Team Agreement

Team agreement is about how our team work together, and NOT about the project we work on.

Example: requirement analysis or decisions on libraries/tools of SERLER should not be put into Team Agreement.

Team Goal

We have dual goals:

1. To learn and practice all aspects of agile software development, and get as much score (i.e. A+) as we can
2. To deliver an excellent product

The goal number 1 has higher priority compare to goal 2.

Roles

Since our main purpose is learning and practicing, so anyone is not limited to a certain role, i.e. each team member can contribute as any role including project manager, developer, tester, scrum master, etc. So actually we are working in a completely decentralized/peer2peer way.

Meetings

Taking into account the lack of availability of in-person gathering:

Face-to-face

• 2 face-to-face meeting in one sprint: sprint planing & sprint review.
• We can add another face-to-face meeting in the mid sprint if necessary (Or can be audio/video meeting if got much time)

Daily stand-up

It seems to be impossible to hold daily stand-up meetings in person or even remotely, so we don't have daily stand-ups but instead:

• Story related discussion: by commenting directly under that story
• Discussion not obviously related to any story: on-demand discussions in asana conversations or slack channel
• Discussion/reviewing of codes: by commenting in pull request or open an issue in Github Issues
• In the ways above, you can make notification/reminder by email or chat (e.g. this is a blocking issue, or you don't get response after a long time), but this is just a notification and the main content should be put in the story/asana/slack/pull request.
• If someone think it an intensive or urgent issue, he can call for a audio/video/in-person meeting, but please inform (email preferred) all team members about the topic/agenda of the meeting in advance so that every meeting participants will know what is going to be discussed.

Documentation

Wiki is the preferable way to document everything needed. We have two wiki systems: AUT Blackboard wiki and Github repo wiki. In order not to be confused by using two wikis at the same time, we are going to use Github wiki to put documents because of convenience and easy version control. Finally we can copy it to Blackboard wiki if necessary.

Product Owner availability

• Email
• Attendance at lecture on every Tuesday
• Slack channel

WARNING: The last point has to be discussed with Jim

User Stories

• All stories have to be prioritized by PO
• The team decides which stories will be developed in current sprint base on story priority
• Anyone can add new stories to backlog
• Information about new stories has to be sent all team members
• Effort for each implementation has to be recorded to give the information for future planning

Development

• Tasks should be done on time by the assignee
• Any blocking issue or delaying factor should be informed to the team promptly
• We follow Git Flow convention preferably
• Code can be merged into master branch only by pull request
• Code review required before merging into develop branch

Testing

• We use automatic test. All test cases should pass before a feature can be merged
• Every feature should come with unit test cases and it is the responsibility of the feature developer