Audience: Web Ops Team and Web Working Group Members.
What: A guide to how Amnesty and BigBite collaborate.
Meetings
Mid-sprint – Every other Friday
- Big Bite will provide an overview of what has been completed in week 1 of the sprint
- Everyone to discuss any issues / pain points identified
- Any other business
- End of Sprint / Demo / Retrospective – Every other Friday
- Big Bite will provide an overview on what has been achieved vs what was originally committed
- Big Bite will demo any new features / blocks developed during the sprint
- Sprint retrospective – What can we fix/make better? What went well / didn’t go well?
- Sprint Planning – Every other Friday
- Big Bite will collaboratively work alongside Amnesty to scope out the plan for the following sprint and estimate complexity of the items within the backlog
- Backlog grooming will be carried out and additions of new tasks where necessary
- The team will discuss how they are going to achieve the sprint goals
- Stand-ups – Daily
- 5-10 minute stand-up to give a quick overview on what each member of the team will be working on that day
Reporting
The Project Manager at Big Bite will be responsible for creating and releasing the following reports to the documentation 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
- Monthly Report
- The Project Manager will create a report on a monthly basis which will outline the hours spent on the project and an overview of what has been completed within that month & any releases that have been released
- 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.
Releases
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
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.
Note: Releases for new features, bug fixes etc; will initially be pushed to the staging environment after Big Bite have carried out internal testing. 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 production for amnesty.org.
Definition of Releasable
Our aim for each sprint, is to deliver releasable features. To achieve this, we will populate the sprint backlog with tasks that are needed to create potentially releasable features.
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
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.
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
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:
- Arrange a meeting to discuss the changes/requirements with UX and Web Ops to approve these
- The BigBite Head of Design & User Experience 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
- Once the mockups are complete, the Project Manager will inform Amnesty that these are ready for review on 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
- Once the designs have been approved, these will be moved to the Development stage, and planned into the backlog for implementation
- 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.