⚙ Auto CI/CD pipeline moves the item — do not touch manually |
✋ Manual Team member must move the item |
User Story Bug
Develop Board Board 1
All active development — work flows here before reaching the Develop server
User Story Flow
Story created & prioritised
Awaiting developer
→
✋ Manual
Developer picks up
Developer working
Developer
PR under review
Reviewer + Team Lead
Awaiting pipeline
Approved ✓
Bug Flow
Bug reported
Module + Server required
→
✋ Manual
Developer picks up
Developer fixing
Developer
PR under review
Reviewer + Team Lead
Awaiting pipeline
Approved ✓
→
✋ Manual
QA starts testing
Fix verified ✓
QA / Tester
Stage Board Board 2
Staging environment — full QA sign-off required before closing
User Story Flow
Auto-promoted from Develop
Created by pipeline
→
✋ Manual
Developer picks up
Developer working
Developer
PR under review
Reviewer + Team Lead
Awaiting pipeline
Approved ✓
Bug Flow
Auto-promoted or reported
Module + Server required
→
✋ Manual
Developer picks up
Developer fixing
Developer
PR under review
Reviewer + Team Lead
Awaiting pipeline
Approved ✓
→
✋ Manual
QA starts testing
Fix verified ✓
QA / Tester
How the Workflow Works
This document describes how the team manages and tracks work across two Azure Boards — one for the Develop environment and one for the Stage environment. Every item, whether it is a user story or a bug, follows a defined path from creation to completion. Some transitions happen automatically through the CI/CD pipeline, while others require a team member to manually move the item.
The Two Boards
The team uses two separate Azure Boards that mirror the two deployment environments. The Develop Board is where all active development happens — this is where items are created, built, reviewed, and deployed to the Develop server. The Stage Board is the second gate — items arrive here automatically after being published to Develop, and they go through another full review and deployment cycle before reaching the Stage environment.
Items are never created manually on the Stage Board. The Stage pipeline automatically promotes them from the Develop Board when it runs.
User Story Lifecycle
A user story represents a feature or piece of work that the team is building. On the Develop Board, a story starts in Todo once it has been created and prioritised. When a developer decides to pick it up, they move it to Active and begin working. Once the code is complete, the developer opens a Pull Request and moves the story to Code Review. At this point, both the Code Reviewer and the Team Lead must review and approve the PR. Once both have approved, the story moves to Ready to Publish, where it waits for the next pipeline run.
When the Develop pipeline runs, it automatically moves the story to Published on Develop. No one should manually move items into this column.
From there, when the Stage pipeline runs, the story is automatically promoted to the Stage Board as New, and the same cycle repeats — Active, Code Review, Ready to Publish, then Published on Stage.
Bug Lifecycle
Bugs follow the same development path as user stories, but they have two additional steps at the end — Testing and Closed — to ensure QA has verified the fix before the work is considered complete.
Every bug must be linked to a Module (the area of the system it affects) and a Server (whether it was found on Develop or Stage) before it is set to Active. This is a hard requirement.
1
New — Bug is reported. Module and Server must be linked before anyone picks it up.
2
Active — Developer picks up the bug and starts working on the fix.
3
Code Review — Developer opens a PR. Both the Code Reviewer and Team Lead must approve.
4
Ready to Publish — PR is approved. The bug waits for the pipeline to run.
5
Published on Develop / Stage — Pipeline runs and automatically moves the bug here. Do not move manually.
6
Testing — QA picks up the bug and actively verifies whether the fix works on the deployed build.
7
Closed — QA confirms the fix is working. The bug is closed. This must never be skipped.
Automatic vs Manual Transitions
Understanding which transitions are automatic and which are manual is critical to keeping the board accurate. Moving an item manually into an automated column will break the tracking and create confusion about whether a deployment has actually happened.
Automated (⚙ Auto): The CI/CD pipeline is the only thing that moves items into Published on Develop and Published on Stage. On the Stage Board, the pipeline also creates the New items automatically when it promotes work from Develop.
Manual (✋ Manual): Every other transition is done by a team member. Developers move items to Active and Code Review. The Reviewer and Team Lead approve and move to Ready to Publish. QA moves bugs into Testing and then Closed.
Key Rules
👨💻Only developers move items to Code Review. Never skip this column even for small changes.
✅Both the Code Reviewer and Team Lead must approve a PR before it moves to Ready to Publish.
⚙Never manually move items into Published columns. That is the pipeline's job and doing it manually creates false tracking.
🔗Every bug must have a Module and Server linked before being set to Active. Do not start without it.
🚫Do not create items on the Stage Board manually. They are auto-promoted from the Develop Board by the pipeline.
🧪Bugs must pass through Testing before Closed. QA sign-off is mandatory — never close a bug without it.