Skip to content

Latest commit

 

History

History
94 lines (67 loc) · 4.15 KB

contributions.md

File metadata and controls

94 lines (67 loc) · 4.15 KB
Raw

Team Agreement

Meeting Schedule:

  • Monday, Tuesday (during lecture time)
  • Wednesday and Thursday (outside of lectures)
  • Weekend if necessary

Meet-up locations:

  • Queen’s Building?
  • Main building (opposite SU)
  • Trevithick library

Daily Scrum and Agile:

  • Daily Scrum to take place at 10:30am for no more than 10 minutes during teaching times where each team member discusses what they worked on the previous day, what they have planned to work on today and if they have any issues that are blocking them from making progress.
  • When outside of lectures, this will be done via Teams with members to post by 12pm each day.
  • Take it in turn to be Scrum Master, changed on a weekly basis

Sprint Planning

  • Understand client requirements
  • Generate a sprint backlog after client meeting
  • Write and assign user stories - They must follow the structure of “As A [Role], I want [Feature] So that [Value] is added”
  • Planning poker - 1-5 point means not too difficult and some effort. 5-10 point means difficult and will require effort.
  • Set a sprint goal for the week
  • Use Taiga to update progress
  • Sprint Review
  • Sprint Retrospective - emotional seismogram and START/STOP/CONTINUE chart using Kaizen

Definition of Done

  • Code completed
    • Code refactored to match existing project, well referenced, commented thoroughly, all TO-DO annotations resolved, checked in and inspected by Peer Review – code review before pull and merge requests (later agreed that this was to be carried out by at least 2 team members). This was decided to prevent merge errors and to help secure working code
    • Use Gitlab for version control
  • The feature is documented
    • Documentation of a feature is to be made in the READ.ME file on Gitlab updated to document changes and explain any feature-specific code
  • All stories are I.N.V.E.S.T
    • Tested
    • Manual unit tests written to test logic and included with in ‘test’ folder in project. Automatic tests optional. All outstanding defects to be resolved. User acceptance testing carried out. Feature works on both web and mobile view platforms
  • Sign Off by Customer
    • Working code ready to be displayed at next Sprint Review, which is subsequently approved by the client at the forthcoming meeting

Definition of Ready

  • Business rules are documented.
  • All stories are I.N.V.E.S.T (Independent, Negotiable, Valuable, Estimatable, Small, Testable).
  • All stories follow the structure of “As A I want So that ”
  • Business value clear and conditions for customer satisfaction are fully identified for the story
  • Details are sufficiently understood
  • Dependencies are identified and resolved
    • No blockers to allow functionality of a specific feature
  • Acceptance criteria are well-defined and testable
  • Performance criteria are well-defined and testable

Working Agreement

As a team we agree to work together having:

  • Daily stand-ups to be held at 10:30 am every Monday and Tuesday
  • To be held via Teams for the rest of the week with each group member contributing by 12pm each day - communicate with other members of the team via Microsoft Teams once a day to update of progress
  • Development made on ‘Development’ branch
  • Follow and work to Agile principles as closely as possible
  • A branch per feature. Work collaboratively on Master branch
  • Pull and push regularly to minimize code conflicts
  • Update the READ.ME file on Gitlab to explain importance and use of feature specific code
  • Update the status of your work on the Scrum board (Taiga).
  • Code reviews to be completed by at least two team members before merging code from a development into master branch
  • If a team-member is late to/missing from the meeting, must inform other members of the team (acceptable to do this via Microsoft Teams)
Links:
References: