Agile workflows: what sits underneath Scrum and Kanban
How teams move work from request to done and how to build a process that holds.
A lot of teams say they work in agile. They still struggle to explain how work moves from request to finished result. They have standups, a board, maybe even sprint planning. Yet the path from "someone asked for this" to "this is done" still feels improvised.
An agile workflow fills that gap. It defines the actual route a task follows through the process so progress is readable, ownership is clear, and the next step is never up for interpretation.
What an agile workflow is, and how it relates to Scrum or Kanban
An agile workflow is the path work takes from request to completion. It shows how a task enters the system. It also shows what has to happen before the team can treat that item as done.
People often mix up workflow and framework because both describe how work gets organized. The distinction is clear. A workflow is the movement of work itself. A framework is the operating model around that movement.
That is where Scrum and Kanban fit in:
- Scrum gives the team a working rhythm through sprints and regular review points.
- Kanban focuses on steady flow and visible work.
- An agile workflow sits underneath either choice and defines the actual route a task follows through the process.
Scrum or Kanban provide the structure around that movement. Iterative delivery can exist without Scrum. But Scrum still depends on a clearly defined path for the work – otherwise the ceremonies have nothing solid to support.
If your team is still choosing between frameworks, that part is covered in kanban vs scrum.
What every agile workflow needs
Three things make an agile workflow reliable, regardless of the tool or framework: iterative delivery, continuous feedback, and adaptive planning.
Iterative delivery keeps work moving in short, repeatable loops. That can take the form of a two-week sprint or a weekly release rhythm. Each cycle should end with something real the team can review. The next round of work then starts from fresh evidence rather than assumption.
Continuous feedback keeps the workflow connected to reality while work is still moving. Teams revisit priorities through reviews or customer input. That helps them correct direction before a small mismatch turns into a finished output no one needs.
Adaptive planning gives the workflow room to respond when new information changes the shape of the work. The team still needs direction, and the process also needs enough flexibility to absorb change without losing momentum.
With those three elements in place, the rest comes down to implementation. A board makes the workflow visible. It shows the stages of work and the movement between them, which helps the team read progress and spot slowdowns early.
How to set one up without overcomplicating it
Start with recent work. Take the last few tasks your group finished and map the path they followed from request to done. That usually gives you a stronger starting point than a framework diagram.
Then keep the workflow small. A handful of clear stages is usually enough to show progress and review points. A board with too many columns gets harder to maintain, so updates slow down and the picture gets blurry.
Make ownership visible at every stage. Each item should have one person responsible for moving it forward. People can then see where work is waiting and who needs to act next.
Then decide how the workflow will stay current, whether that happens during daily work or at fixed review points. Once the board stops updating, the workflow stops telling the truth about the work. And if the workflow itself was never described, the board shows nothing meaningful in the first place.
Two patterns teams use
The easiest way to understand an agile workflow is to compare two teams with very different rhythms.
Product team with short iterations
Maya’s product team works in weekly cycles. On Monday, the team pulls 4–6 items from the backlog. They move through Ready → In progress → Review → Done. The team checks results at the end of the week. The rhythm stays fixed, so each cycle gives the next one a clear starting point.
In a setup like this, agile ceremonies help the team review and adjust the work. The workflow still defines how that work moves.
Marketing or ops team with continuous flow
Lena’s marketing team does not use sprints. Around 8–12 briefs arrive each week. The work moves through a lighter flow: Requested → In progress → Review → Published. The focus here is steady movement, with priorities updated as new requests come in.
That model suits teams that handle a constant stream of work and need visibility without waiting for a sprint boundary.
The right pattern depends on how work reaches the group and how quickly people need to respond. Teams usually see the fit faster when they look at the real pace of incoming work. Starting with the framework name often slows things down.
How this looks in Vaiz
Vaiz isn't built specifically around agile. But agile workflows fit naturally – the team can keep boards, tasks, and iteration markers in one place.
Teams can use boards with custom columns such as Not started, In progress, Review, and Done. Tasks then move through that flow as work advances. Each item stays tied to a task with a clear owner and a due date. The team sees both status and responsibility without switching tools. When the team works in iterations, milestones can mark those cycles on the timeline. They keep the rhythm visible next to the work itself.
A workflow starts proving itself when the team can describe it clearly. It also needs to be reflected in the board they use every day. That is usually when "we work in agile" starts meaning something concrete.