Guidelines
Ways of Working
Definition of Ready
- Kick off with developers, testers, and backend (where relevant)
- API / mock definition and data written in the ticket
- Design assets signed off and linked to the story
- Architectural discussions have been captured
- Gherkin ACs describing all expected behaviour
- Tickets are broken down to the smallest testable chunk
- Ensure not blocked by another ticket that isn't in the current sprint.
- Accessibility considered
- Analytics considered
- Dependencies & API mapped to ticket
- Test data attached
- Feature flagging delineated
- Config requirements documented
Raising backend issues
The backend team are currently pulled in a lot of directions, and we want to make sure we make life as easy as possible for them to understand issues we raise, triage whether it's for them to resolve, and sequence that in their ongoing workload. With this in mind, if you suspect that there is a backend issue causing something you're building or testing to not work as expected, please do the following:
- Create a MOB bug ticket using the bug ticket template (i.e. give clear steps to reproduce the issue)
- Assign it a priority based on the scale below
- Assign that ticket to the Sprint "Backend issue triage"
- These tickets will then be triaged by with the backend team in the regular tech leads stand up on Tuesdays and Thursdays.
- If your issue is critical, message Colin directly to notify him
Backend Priority Levels
- Critical - blocking progress of dev / test in current sprint & affects multiple high priority tickets
- P1 - affecting dev / test of issue that is in progress during the current sprint
- P2 - affecting dev / test of issue due to be worked on in current sprint
- P3 - change that needs to be made for upcoming work (not current sprint) / non-critical change unrelated to team's backlog