Ways of Working – Phase 2

During the Agency engagement with Amnesty International for phase 2 of the amnesty.org project, the development agency would like to outline the ways in which they wish to work collaboratively with IS Web Ops, to ensure that the development agency and IS Web Ops are all on the same page as the project evolves.

Meetings

The following meetings have been scheduled and set up as of Thursday 19th August 2021:

  • Weekly Progress Sync – Every Friday from 11:00am – 11:30am
    • Big Bite Project Manager will provide an overview of what has been completed in the current week of the sprint
    • Everyone to discuss any issues / pain points identified
    • Sprint planning on the last week of the sprint / discuss any tickets added to the ‘Next Sprint’ column on the project board
    • Any other business
  • Monthly Account Review – First Friday of the month 12:00pm – 12:30pm
    • Big Bite Project Manager will provide an update on the following areas:
      • Hours logged vs budget for the month 
      • Team velocity (per sprint & per month)
    • Any other business

Reporting

The Project Manager at Big Bite will be responsible for creating and releasing the following reports to the Amnesty WordPress Docs website:

  • Sprint Report
    • The Project Manager will add the goals this at the beginning of the sprint 
    • The Project Manager will add what has been achieved & schedule for next sprint at the end of the sprint
  • Release Doc
    • The Project Manager will create a release document for each release that is actioned
  • Incident Report
    • The Project Manager will provide an incident report where required) to outline any major downtime, lost data etc and explain what happened & the steps we will take to mitigate and/or prevent it from happening again.
  • Feature Documentation
    • The Project Manager will assist the Amnesty PM to update feature documentation

Sprints

Process:

  1. Web Ops will use the Product Board to move tickets through the following columns:
    • Product Backlog – Collect – New items are added here, these items will be prioritized by David and will be moved to the next column when sizing and AC is deemed useful.
    • Product Backlog – Temp Lane from “full product” and “MVP” – Items from the old “MVP” and “Full Product” have been moved here. Also items not release from Sprint 25 and 26 will be added here after the completion of sprint 26. David to move items to either “collect” or “refine”. Austin to delete this lane when the above is done.
    • Product Backlog – Refine – During backlog refinement meetings epics will be broken down into features, large features into small features. This features will be sized and have acceptance criteria written.
    • Product Backlog – Sprint Ready – During backlog refinement meetings items will be moved here when they are “Sprint Ready” and should require no further discussion before development. David will order items here.
    • Next Sprint – During the sprint planning meeting items totalling a given number of story points (the past velocity) will be select by David and moved here.
  2. Once tickets hit the Next Sprint column, they will be moved to the Development Board (that Big Bite will control) and tickets will be moved to the To Do column, once the new sprint is started. The following workflow will be managed:
    • To Do – Tickets committed to the sprint will sit in this column until picked up by an engineer
    • In Progress – Tickets will be moved to this column once an engineer has picked it up for development
    • PR Created (ready for review) – Tickets will be moved to this column once the engineer has actioned the request and created a pull request into the develop branch, which requires a review from a peer. The ticket will be closed once it moves to this column to reflect the work being done
    • PR Feedback Requested – Tickets will be moved to this column if the PR has been reviewed, but there is feedback required before it can be merged.
    • PR Approved (ready for DEV) – Tickets will be moved to this column once the PR has been reviewed & approved by a peer on the project
    • Merged to DEV (internal testing) – Tickets will be moved to this column once the PR has been merged to the DEV environment and is ready for internal testing by the Big Bite QA team.
    • Approved to Merge (to STG) – Tickets will be moved to this column once they have passed internal testing. The QA team will leave a comment on the ticket to show the tests been carried out.
    • Merged to STG (ready for UAT) – Tickets will be moved to this column once the Lead Engineer has PR’d into the staging branch and merged to STG environment. The ‘UAT’ label will be automatically added via automation and the ticket will be assigned to Web Ops to be tested.
    • UAT Approved (ready for release) – Tickets will be moved to this column once the client is happy that the acceptance criteria has been met and are happy with the change. Client is responsible for leaving an approval / sign-off comment on the ticket. The ‘UAT Approved’ label will be automatically added via automation. The Big Bite Project Manager will add the ticket to the ‘Release Candidate’ ticket. The Lead Engineer will then merge the PR branch into the main branch
    • Released to PRD – Tickets will be moved to this column once the release has been deployed to Production (PRD).

Releases

Versioning:

Big Bite will utilise GitHub Releases to manage releases in the repository. We will use semantic versioning (e.g. version 1.2.3) when creating releases which will allow for the following release structure:

  • Major Version (1)
    • Includes backwards incompatible/breaking changes
  • Minor Version (2)
    • New features/functionality
  • Patches (3)
    • Bug fixes

Process:

The following process will be followed when prepping and deploying a release:

  1. Tickets that have been UAT approved will be added to a Release Candidate ticket (created by the Big Bite Project Manager) The Release Candidate ticket will list the following:
    • Tickets slated for release
    • Link to release document
    • Scheduled date of release
  2. A release version number will be assigned based on the type of changes in the release
  3. It will be the responsibility of the client to provide sign-off on the Release Candidate ticket to give the approval for the release before it can be deployed
    • This can be in the form on a comment on the Release Candidate ticket
  4. The Lead Engineer will create a draft release in GitHub
  5. The Big Bite Lead Engineer will then deploy the release to main branch (production)

Documentation:

A Release doc will be created alongside this, which will detail what fixes/amends/features are included in the release. This will be added to Amnesty WordPress Docs.

Frequency:

We will aim to create a release at the end of each sprint, but will remain flexible if we need to push out an urgent release for any reason. We will also work on moving plugins over to separate repositories, so these can be separately versioned and kept apart from feature releases.

Week 1 of a sprint will be purely for dev work, with the cut-off for releasable tickets on the last Wednesday of the sprint. Anything not passed UAT by that Wednesday, will miss the release.

Releases will be deployed on the last Thursday of the sprint (week 2 of the sprint). Release prep will begin on the Wednesday, pending final sign-off on the release candidate ticket. The release can be deployed as early as possible on the Thursday.

Note: Releases for new features, bug fixes etc; will initially be pushed to the DEV environment for Big Bite to carry out internal testing. Once happy, Big Bite will merge the code to STG (UAT). This environment will be used for UAT and once both parties are happy and confident the release will not cause any issues; we will release this to PROD.

Definition of Releasable

Features that will be classed as ‘releasable’ will meet the following criteria:

Well Tested – A feature/block/integration that is ‘potentially releasable’ must be fully & well tested internally.

High Quality – As well as being tested fully, the engineers should fix as many of the bugs so the feature/block/integration can be considered high quality. This may not necessarily mean that all bugs/issues have been fixed, but all bugs/issues that are high in severity or frequency, must be fixed.

Complete – To class the feature/block/integration as ‘complete’, all sub-tasks of the ‘epic’ must be completed. For example, the epic may have a total of 6 sub-tasks, one of those being that documentation has been created for the feature; this should be completed alongside the functionality, in order to consider the epic, complete.

Content Coordinator Checks – The feature should be tested and checked by the content coordinator. Once the feature has been approved, it can then be released.

UX UI Checks – Features where the front end UI or UX changes should be tested and checked by the UX team and should work as per the Invision prototype. Once the feature has been approved, it can then be released.

What happens if the feature is not releasable?

If the feature fails or doesn’t quite meet any of the above criteria, new issues will be added to the backlog and planned into a future/following sprint to be actioned. The process above will then start again.

User Stories & Acceptance Criteria

User stories will be created for each feature/block/integration etc at an ‘epic’ level. Writing these at an ‘epic’ level means that we can identify and break down the work that needs to be done, in order to achieve the end goal. For example, an epic for a block, could have 5 sub-tasks attached to it, which means the epic can only be classed as ‘done’, once those sub-tasks are completed.

Acceptance criteria must also be provided for all tickets, no matter their size. This will help the QA team when they come to test the change. Acceptance criteria will also help understand how the change should work and aid the creation of documentation for the change.

Our User Stories will be set out as follows:

What is required? – Explains what is the end goal of the feature/block/integration etc and what work is involved to achieve the goal

What does this rely on? – e.g. do we need access to any third party systems in order to achieve the end goal?

What is the end goal? – Explains how the block/feature should work once developed

Definition of Done (DoD)

The DoD is a checklist of criteria that the product/feature/block etc must satisfy in order to be considered ‘complete’. We use this as part of our agile project management workflow.

Our DoD is outlined as follows:

Code is reviewed – PRs are created and internally reviewed by the Lead Engineer

PR is approved & merged – Once approved, the PR is merged to the test environment and the feature/block/integration is tested against the acceptance criteria

Acceptance criteria met – The feature/block/integration meets the requirements set out in the user story

Smoke & Regression tests are passed – Automated tests are written for the feature and carried out (platform TBC)

User acceptance testing (UAT) is passed – The feature is approved the Product Owner

UI/UX Changes & Testing

If we need to change the front end UI/UX of a feature/block etc, the following steps will be carried out:

  1. Arrange a meeting to discuss the changes/requirements with Kevin (UX) and Austin Meakin to approve these
  2. The BigBite Head of Design & User Experience (Jonny Waters) will create mockups of the changes on the required devices and export these to InVision, where Amnesty can view and leave comments/approve the designs
  3. Once the mockups are complete, the Big Bite Project Manager will inform Amnesty that these are ready for review on Figma / InVision.
    • A further call may be arranged to review the designs, or comments may be left on InVision with amendments to be made/approving the designs
  4. Once the designs have been approved, these will be moved to the Development stage, and planned into the backlog for implementation
  5. Work going through this workflow will also required a final check from AI UX before the work is released.

Secure Sharing of Passwords

In the interest of security, we will not share or expect Amnesty to share passwords/secure login details via channels such as Slack, GitHub, email etc. Information available on request.