Delivery
Two boards, one flow.
The sprint board tracks the team's work. The release board tracks where the code really is. A story isn't done until the release board shows it live.
Why two boards?
"Done" on a sprint board usually means the code is reviewed. It doesn't mean it's in front of users. Most tools stop there, and the release happens somewhere else.
FlowGazer splits it in two. The sprint board is the developers' work: build it, review it. The release board is Ops and QA's work: deploy it, test it, sign it off. Different people, different questions, one story.
How a story crosses over
- Its review is approved on the sprint board: the story is verified.
- It appears in Handover on the release board. Nobody has to copy it.
- Ops claims it and deploys to dev; QA claims it and tests.
- Once QA gives the green light, it's promoted to staging, then to production.
Sprint planning
Scrum masters and leads plan the sprint from the backlogs of the team's products: a goal, a length and the stories, in order. Only estimated stories can go in.
The sprint board and four eyes
Stories and their tasks move through to do, in progress and peer review.
Review needs a pull request
A story goes to peer review with its pull request link.
Someone else approves
The author can't claim or approve the review; a teammate does. Managers can step in when needed.
Rejected with a reason
A rejected review goes back to in progress with feedback for the developer.
The release board
Dev, staging and production. Ops deploys, QA signs off at each step, so the board shows where the code really is.
When QA says no
- The story moves back one environment: production to staging, staging to dev, dev back to review.
- It turns red, with QA's feedback on the story (feedback is required).
- The QA and Ops claims are cleared; the developer stays assigned.
- The rejection is logged on the story.
See how sprints really go
Per team: committed, verified and delivered points per sprint; predictability over the last sprints and a rolling average to plan with; a day-by-day burn-up; and the history of what each sprint delivered and what it didn't.