How the flow works
Stop reinventing your process. Run a proven one.
FlowGazer is opinionated on purpose: instead of a blank canvas you have to design yourself, you get a workflow shaped by years of engineering leadership, from the first idea to production.
Why a fixed flow?
The problem
Most tools let every team design its own process. Rules end up in people's heads, steps get skipped under pressure, and “done” means something different in every team.
The idea
One way of working, the same for every team: a story moves through fixed stages, and each move has an owner and a condition. You adopt the flow instead of configuring one.
How it holds
FlowGazer checks every move. If the condition isn't met, the move is refused and you see why, so the process still holds on a busy Friday.
Four stages, one path.
Every story follows the same path. Each stage has an owner and a gate.
- Idea Anyone writes it down
- Discovery Pre-work: feasibility, UX, designs
- arrow_downward Gate:A product manager says ready
- Backlog Ranked, estimated in grooming
- arrow_downward Gate:Has an estimate
- Sprint To do, in progress, peer review
- arrow_downward Gate:PR link + approved by someone else
- Release Dev, staging, production
- arrow_downward Gate:QA and Ops sign off
- Live Done means in production
undo Going back is part of the flow: a refused review returns the story to in progress, and a QA rejection sends it back one environment.
| Stage | What happens | Who | The gate |
|---|---|---|---|
| Discovery | Work the story out: pre-work tasks for feasibility, UX research and designs. | Product manager, with the people doing the pre-work | Only product managers move a story to the backlog. |
| Backlog | Ready stories, ranked by priority; the team estimates them in grooming. | Product manager, team | A story needs an estimate before it can enter a sprint. |
| Sprint | The team plans the sprint and works it: to do, in progress, peer review. | Scrum master or lead plans; developers work; a reviewer approves | A review needs a pull request link and someone other than the author. |
| Release | Dev, staging and production on the release board. | Ops deploys, QA signs off | Only the assigned QA or Ops (or a manager) signs off; a QA rejection sends the story back. |
Checked by FlowGazer, not just the screens.
The gates aren't hidden buttons: FlowGazer refuses the move, with the reason, however the request is made.
Four eyes on every change
Nobody reviews or approves their own work. The review is claimed and approved by someone else.
Ready means ready
Stories reach the backlog through a product manager, and the sprint only with an estimate.
Done means live
Release stages move only on the release board, signed off by QA and Ops.
A person moves the story. On purpose.
Automation can write code, open pull requests and deploy. That's good, but someone still has to answer for what ships. In FlowGazer every move is made by a person, and their name is on it: who said a story was ready, who approved the review, who signed off the release.
GitHub stays the source of truth for your code. FlowGazer is the record of who decided what.
When real life happens
People get ill and fixes get urgent. Managers (scrum masters, leads, product managers and admins) can step in, for example to approve a story when its reviewer is away. Guardrails, not handcuffs.
What the flow believes in
The board tells the truth
If the board doesn't show where the code really is, the board is lying, and a lie on the board is a risk for the business.
Questions before the sprint
Unclear stories cost the most in the middle of a sprint. Discovery answers them first.
People decide, tools support
FlowGazer guides and checks; your team makes the calls. AI helps when you ask, it doesn't do the work.