Agile Workflow: From Idea to Done in Five Steps

An agile workflow is the path a piece of work takes from idea to done, written down so the whole team moves work the same way. The simplest one that works has five steps: capture the idea, shape it until someone could start, commit to it, build it, and finish it against a definition of done. Those steps live on a board as four states, To Do, Next Up, In Progress and Completed, and each move between states has one pull rule: a short test the task must pass before it moves. That is the whole process. Below are the steps, the rules, and a worked example board you can copy.

If you want the background first: what is agile covers the idea in plain terms, and the Agile Manifesto has the four values and twelve principles behind it. This page is the working part.

Why write the workflow down

Every team already has a workflow. Usually it lives in people’s heads, and it differs by person: one developer starts anything that looks interesting, another waits to be told, and nobody agrees what “done” means. Writing it down turns habits into a shared agreement. The Kanban Guide↗ (opens in a new tab) calls this the Definition of Workflow, and asks for a few things at minimum: what the work items are, when an item counts as started and finished, the states it flows through, how work in progress is controlled, and “explicit policies” about how items move through each state. The five steps below cover all of them in about a page.

The agile process in five steps

1. Capture. Any idea, request or bug goes on the board the day it arrives, as one line starting with a verb. It lands in To Do. Nobody judges it yet.
2. Shape. Before work starts, the task gets a note that says what is wrong or wanted, why it matters, and how anyone will know it is finished. A task nobody could start tomorrow is not shaped yet.
3. Commit. The person who owns priorities pulls shaped tasks into Next Up, in order, until the next week or two is full. This is agile planning in its smallest form: deciding what comes next, often.
4. Build. When someone has room, they pull the top task from Next Up into In Progress and put their name in the first line of the note. Finish it before starting another.
5. Finish. The task moves to Completed only when it meets the definition of done. Then it gets shown to someone it was for, and what they say becomes new tasks in To Do.

Step five feeds step one. That loop is the difference between an agile workflow and a to-do list: what you learn from finished work changes what you do next. The federal government’s Digital Services Playbook↗ (opens in a new tab) puts the same idea plainly in its fourth play: get “working software into users’ hands as early as possible” so the team can adjust based on what users say.

States and pull rules

A pull rule is the test a task passes to enter a state. Write one per state, keep each to a sentence, and put them where the team will see them. Here is a starting set:

To Do        Anyone may add a task. One line, starts with a verb.
             Kind is set: feature, enhancement or bug.

Next Up      Pulled in by the priority owner only.
             The note says what, why, and how we will know it is done.
             No more than two weeks of work in this lane.

In Progress  Pulled by the person doing it, from the top of Next Up.
             Their name is in the first line of the note.
             At most two tasks per person, and finish before you start.

Completed    Meets the definition of done, checked by someone
             other than the builder when the task is risky.
             Closed tasks say why: shipped, won't fix, duplicate.

Notice what does the work here. Only one person pulls into Next Up, so the order means something. People pull into In Progress themselves, from the top, so nobody is assigned three things at once and the most important task starts first. And “at most two per person” is a work-in-progress limit the team agrees and keeps; the Kanban Guide explains that controlling WIP is what creates a pull system, where people start an item “only when there is a clear signal that there is capacity to do so.” How to set the number is covered in kanban WIP limits.

The definition of done

The last pull rule needs its own list, because it decides what “finished” means for every task. The Scrum Guide↗ (opens in a new tab) describes the Definition of Done as “a formal description of the state of the Increment when it meets the quality measures required for the product,” and says it creates transparency by giving everyone “a shared understanding” of what was completed. You do not need Scrum to use one. A small software team might start with this:

• The change does what the note said, and someone other than the builder has tried it.
• Tests pass, and a test was added for the bug or the new behavior.
• It is live, or merged and waiting only for the next scheduled release.
• Docs and the changelog are updated, or the task says why they did not need to be.
• The person who asked for it has been told.

Keep it to five or six lines, and change it at a retrospective, not mid-task. Ready-made lists for software, web, content and AI-assisted teams are in definition of done examples.

An agile workflow example board

Here is the board for a four-person team that runs an online store for outdoor gear, two weeks into using this workflow. The goal for the month is “customers can see shipping cost before checkout.”

TO DO
  FET-31  Save a cart for later               (captured, not shaped)
  ENH-29  Show delivery dates by ZIP code     (shaped)
  BUG-33  Coupon field accepts expired codes  (captured Monday)

NEXT UP                                       (priority owner: Dana)
  ENH-27  Shipping estimate on the cart page  P2
  FET-28  Free-shipping threshold banner      P4

IN PROGRESS
  ENH-26  Shipping rates API for cart         Marcus
  BUG-30  Sales tax wrong for Colorado orders P1, Priya (pulled 9:10)

COMPLETED
  ENH-24  ZIP code field on product page      shipped
  BUG-25  Duplicate order emails              shipped
  FET-22  Gift wrap option                    won't fix: no demand

Three moves show the workflow doing its job. BUG-30 came in Monday, Dana judged it more urgent than the shipping work and put it at the top of Next Up, and Priya pulled it the next morning because she had room. Nobody had to reassign anything. FET-22 is in Completed with a reason, so it counts as a decision rather than a delivery. And ENH-29 is shaped but sits in To Do, because Next Up already holds two weeks of work. When ENH-27 ships and the team shows it to a few customers, what those customers say decides whether ENH-29 or FET-31 comes next.

Agile practices that keep it honest

• A short daily look at In Progress. Anything that has not moved in two days gets a question, not a lecture.
• A weekly reorder of Next Up by the priority owner, with the team in the room. The routine is in how to organize tasks at work.
• A show-and-tell every week or two, where finished work is put in front of someone it was for.
• A retrospective once a month: one change to the pull rules or the definition of done, written down.
• Split anything that sits in In Progress for more than a week. Big tasks hide problems.

If your team works in fixed-length sprints, the same five steps fit inside each one; Next Up becomes the sprint’s list. If it does not, keep pulling continuously. The workflow does not care which, as long as the rules are written down and kept.

Running this workflow on fenbs

fenbs is a simple task board where people and AI assistants work side by side, and its four fixed lanes are the four states above: To Do, Next Up, In Progress and Completed. Every task is a feature, an enhancement or a bug, with a priority from 1 to 10 where 1 is most urgent, a note for the problem, a plan for how it will be done, and a test status with test notes, so the definition of done has a place to be checked. A task in Completed is marked Completed, Won’t fix, Duplicate, Cannot reproduce or Obsolete, so only shipped work counts as delivered. Add many turns a pasted list into tasks for the capture step, and History records who moved what.

Your pull rules and definition of done belong on the Decisions and rules page. A person decides each rule, and every connected AI assistant reads the rules before it starts, so an assistant that picks up a task from Next Up follows the same workflow as everyone else. Be clear about what fenbs does not do: it has no sprints, no due dates, no settable assignee field and no WIP limit setting. The name in the note and the limit of two per person are rules the team keeps, not something the board enforces.