Agile Workflow — from requirements to release, on a loop
An agile workflow on an interactive canvas: requirements, backlog, sprint, demo, stakeholder acceptance, release and the retrospective that feeds the next loop.
An agile workflow turns customer needs into released value in short loops: requirements flow into a prioritised backlog, a sprint turns a batch into a working increment, stakeholders accept or reject it, and the loop repeats.
Agile Workflow — from requirements to release, on a loop
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read the four columns left to right as one delivery loop: what is prepared, what is built, what is judged, what is released.
- The three rows are owners — product owner for the backlog, team for the sprint, stakeholders for acceptance.
- The "Stakeholders accept it?" decision is the loop's hinge: "No" points backward to requirements, "Yes" forward to release.
Preparing the work
"Gather and refine requirements" and "Prioritise the backlog by value" are the product owner's contribution: turning customer needs into a ranked list the team can pull from. "Sprint planning commits to a batch" moves from the Backlog column into the Sprint column — the team selecting the items it will deliver.
Doing the work
"Daily stand-ups keep work visible" and "Develop, test and integrate" are the team lane's sprint: short alignment meetings and continuous work toward a working increment. The visual keeps them adjacent and in the Team row because self-organisation is the agile principle at work — the how of the sprint belongs to the team.
Judging and releasing
"Demo the working increment" hands the result to "Stakeholders accept it?" — the decision owned by the stakeholders row. Acceptance routes to "Release to users"; rejection routes back to requirements so the work is reshaped, not forced through. "Retrospective feeds the next loop" closes the cycle from the Team lane: the team's own improvement becomes the input to the next round.
Key relationships and takeaways
- Agile is a loop: every release's feedback and every retrospective reshape the next iteration.
- The product owner orders the backlog; the team commits to a batch; stakeholders judge the result.
- Acceptance is the gate — an unaccepted increment goes back to requirements rather than forward.
- Working increments and short loops replace the assumption that a long plan is a good plan.
- The retrospective is where the process itself improves, separate from the product's acceptance.
When to use this visual
- Introducing the agile loop to a team or stakeholder who has only seen waterfall.
- Auditing an agile practice: the acceptance gate and retrospective are the two steps most often quietly dropped.
- Documenting your team's delivery flow before adopting a tool or scaling framework.
How it works
Rename the roles to your team
Replace Product owner, Team and Stakeholders with your real roles — a design team, an ops team, a customer committee — and merge or split lanes to match.
Add your actual ceremonies
Insert the meetings your team really runs — refinement, review, a showcase — as steps between the boxes, each in the lane that owns it.
Make the feedback loop concrete
Annotate the retrospective with the improvement your team is currently tracking, and the release step with your real cadence, so the loop is grounded.
Add the release branches
If your team deploys to production on a schedule or on demand, add the branch that fits and its triggers, each ending in an explicit state.
Frequently asked questions
What is an agile workflow?
An agile workflow is a way of organising work that delivers value in short, repeating loops: requirements are gathered and prioritised, a team commits to a batch, builds and tests it, demonstrates the result, and the acceptance and retrospective feedback reshape the next iteration. Its defining property is that feedback from each loop changes the next, rather than a plan being fixed in advance.
How is agile different from a waterfall workflow?
Waterfall completes each phase — requirements, design, build, test — before starting the next, delivering everything at the end. Agile runs the phases in short loops, delivering working increments frequently and adjusting the plan from feedback. The canvas's loop shape is the structural difference: a waterfall diagram is a straight line, an agile one is a circle with acceptance and retrospective feeding back into it.
Who decides whether work is accepted in agile?
The stakeholder or customer who will use the work. Agile's contract is that the team delivers working increments often and the customer's acceptance — not a pre-agreed specification — determines whether an increment is good enough. That is why the acceptance decision in the visual sits in the stakeholders row, with a rejection path back to requirements.
What role does the retrospective play in an agile workflow?
The retrospective is the loop's self-improvement step: the team reviews how the last iteration went and commits to one change for the next. It is separate from the acceptance review, which judges the product. Agile without a retrospective is a loop that repeats its own mistakes — the retrospective is what makes the second lap better than the first.
Edit this visual in QueryChart (FlowJam)
Open this exact agile canvas as your own chart, rename the roles and stages to your process, and add your real gates.