Team Playbook

Appearance

Task Workflow ​

Every piece of work follows this order:

  1. Receive the request — from the lead, PM or BA via Slack or Jira.
  2. The BA files the work item in Jira — a Story (or anyone files a Bug or Task) with the goal and what is known so far.
  3. Refinement — an assigned engineer researches and posts questions; the BA answers by writing the detailed spec into the description. Examples are in Jira work item examples.
  4. Refinement review — engineer, BA and lead read the spec; engineers create and estimate their subtasks and tag each test scenario auto or manual; the lead confirms the estimates and moves the work item to Ready. Work does not start before this.
  5. Execute — branch as <type>/<SUBTASK-KEY>-<short-description>, open the MR with the key in the title and Closes <SUBTASK-KEY> in the description. Each MR includes the automated tests for the auto scenarios it implements. Merging moves the subtask to Done; when all subtasks are Done the work item moves to In Verification.
  6. Verify on staging — the work item owner runs the manual scenarios on the staging build and posts the results with the build version. The BA then checks the feature against the spec on the same build, posts "Accepted on build #...", sets the Fix Version and moves it to Ready for Release.
  7. Release — on the next release day the work ships in its Fix Version. Releasing the Jira version moves the work item to Done.

Work item requirements ​

By the end of refinement the description is a detailed spec that someone who wasn't in the room could build and test from. The template is in conventional/jira.md:

  • Goal — who needs what, and why.
  • Flow (optional) — the happy path step by step and what can go wrong, when the feature spans several steps. Otherwise the failure cases go under Rules.
  • Endpoints — the ones we will support, one line each with a note: paging, filters, what comes back. No request/response bodies; those live in Swagger.
  • Rules — business rules and edge cases.
  • Acceptance criteria — Given / When / Then.
  • Test scenarios — one per criterion and failure case, tagged auto or manual.
  • Notes (dependencies, out of scope) and open questions (empty before Ready).

If the spec can't be completed, the work item is not moved to Ready and engineers don't start.