A Software Development Workflow From Request to Release

A software development workflow is the path a request follows until the change is in production and someone owns what happens after. It says who captures the request, when it is ready to build, how the code gets reviewed, and what "released" means. Once the path is written down, work stops disappearing into chat and status meetings.

What a software development workflow covers

The workflow is a series of decisions, and each one leaves an artifact. A request comes in and someone decides whether it is worth doing. A person or an agent implements it, a reviewer checks it against what was agreed, and a release puts it where users can reach it. Afterwards you look at cycle time, defects, and unfinished work.

A workflow is usable when four things hold:

• After a request leaves chat, a call, or an error report, it lives in one place.
• Every stage has an exit check that a second person can apply without calling a meeting.
• The branch, the review, and the release all stay attached to the same ticket.
• Unfinished work moves into the next cycle with a reason attached, so it doesn't vanish.

Stages from request to release

Only add stages you will enforce. A small product team can get by with seven or eight, renamed to match your board. Work tends to sit in any column that has no exit check.

Capture the request

Requests show up as chat, client calls, support email, or production errors. Write each one down the same day, in the asker's words, with a symptom you can verify, and link the source. For an error, keep the stack trace, the release, and how often it fires. For a meeting, keep the decision and who must confirm it.

Capture is intake. It doesn't commit you to anything, and you can still decline later. "Checkout feels slow" is a mood. "After 14:00 UTC, Pay now spins, the cart reloads, and no order appears" is something you can triage.

Triage

Triage answers four questions. Is this a bug, a change, or a question? Who is blocked? What happens if it waits a cycle? Does it belong in this product at all?

The outcome is decline, defer, or accept. Accepted work gets a type, a priority, and a stage. Questions go back to the asker, and the answer goes on the ticket. A short note is enough: "Timeout after deploy 1.42. Users on checkout. Accept as a bug. Ready when the reproduction is on the ticket."

Bugs and features pass through different gates. A bug might go from Captured to Reproduced to Ready, while a feature goes from Captured to Scoped to Ready. Falrow keeps those gates on the work item through ticket types, triage, and workflow rules. A strict issue tracker can do the same, as long as a ticket with empty fields can't leave its column.

Make it ready

A ticket is ready when a builder can start without hunting for the intended outcome:

1. It names the user and the situation.
2. Done is something you can observe. "Improve" doesn't count.
3. The scope says what is excluded.
4. Dependencies and permissions are listed.
5. It meets your definition of ready, including how you will test it.

Large requests need a product requirements document before they count as ready. Small ones need a tight ticket. If you mix the two up, a one-line fix can turn into a redesign on the same branch. Name the risks you don't want to discover halfway through the build: billing, auth, migrations, and anything a customer sees in their first session.

Plan against the repository

Planning means reading the code you will touch, then naming the files, the tests, the risks, and the order of work. For a human, that is a short comment. For an agent, it is a plan the team can reject before anything is written. If the default branch has moved since, read it again. Then pick one approach.

Build

Keep the dev workflow boring. Branch from the current default branch, commit in slices a reviewer can follow, and put the ticket id in the branch name. Each ticket gets its own branch and a single outcome.

If the work turns up a second problem, file a second ticket, because fixing it on the side hides scope. Agents can write the branch, but they shouldn't invent the outcome. Their assignment is the ticket, the plan, and the repo rules.

Review

Review checks the change against what was agreed, regardless of how much effort went into it. Look for the outcome, the tests that prove it, and anything nearby the change might break. Use your definition of done as the checklist. Merged code isn't done while the flag, the migration, or the runbook line is still open. If the reviewer can't say "this matches the ticket" without a call, the ticket goes back to ready.

Release

A release needs a window, an owner, and a way to roll back. Put the change behind a flag when it touches money, auth, or a migration. Record the version, the tickets it includes, and who watches the first hour.

Small teams don't need a release department, but they do need the habit described in release management for small software teams: what ships, what waits, and how you roll back. If production misbehaves, the new error goes back to capture. Decide what "released" means for your product, whether that is a deploy plus a flag, store approval, or a published version.

Close and roll forward

Close a ticket only once the outcome is in production or has been explicitly dropped. Anything still open at the end of a cycle rolls forward with a note saying whether it is blocked, still being built, or split. Dropping work is fine. Explain why, tell the asker, and leave the ticket readable so the next person doesn't have to triage it again from a screenshot.

Where an agile development workflow fits

An agile development workflow is the same path run in short cycles, with a backlog you keep re-ranking and a working increment at the end of each one. The Scrum Guide describes the events. It says nothing about your intake form, your branch rules, or your release window.

Sprints and kanban break down at the same point: when there is less ready work than capacity, people start pulling vague tickets. Fix the ready gate before you redesign the meeting. Forecast as a range, based on tickets you have already finished. A team that usually finishes four to seven tickets a week might hear "about eight to fourteen over the next two weeks."

Worked example: a checkout timeout

On Monday a support note says three customers couldn't pay after 2 p.m. The button spins, then the page reloads. Within the hour someone captures it along with the payment error, a timeout calling the tax endpoint on release 1.42.

Triage happens the same morning. Checkout is blocked, so the fix goes into this cycle. The ticket is ready once the timeout is reproduced on staging and the outcome is written: if tax takes longer than two seconds, checkout shows a retry and doesn't create a second order. The cart redesign is out of scope.

The plan names two files, one test, and one risk. The retry has to reuse the idempotency key, or a slow call becomes a double charge. The branch, bug/checkout-tax-timeout, holds a failing test, the timeout handling, and a runbook line. Review checks the test, the key, and the definition of done.

The release goes out Tuesday afternoon with the flag on for a slice of traffic and one person watching errors for an hour. After that the flag opens fully. On Wednesday the ticket closes with the version recorded, and "the tax client has no metrics" becomes its own ticket.

That one bug runs through the whole workflow of software development: request, triage, ready, plan, build, review, release, close. A feature goes through the same stages and spends longer in ready and plan.

Rules that keep handoffs small

Write your rules as checks. On a busy day, people skip any check that doesn't produce an artifact.

Stage	Artifact you can open	Exit check
Capture	Ticket with source and symptom	A second person can tell what was asked
Triage	Type, priority, accept or decline	The asker knows the decision
Ready	Outcome, exclusions, dependencies	A builder can start without a meeting
Plan	Files, tests, risks	The approach matches the current tree
Build	Branch tied to the ticket	The change does the ticket and nothing extra
Review	Notes against the outcome	Definition of done is met, or exceptions are named
Release	Version, owner, rollback	The change is reachable and someone is watching
Close	Done or dropped, with evidence	Nothing is left "almost" on the board

A request that only exists in chat isn't in the workflow until it becomes a ticket. The roadmap should be a count of tickets; a theme with no tickets behind it is still just a wish. Technical debt needs a cost attached, or it loses triage to any feature with a customer waiting. Put technical debt on the same board, because a "cleanup" label with no owner is where work gets lost. Agents follow the same checks when the rules live on the ticket, in the repo, and at a gate that runs before a write is kept.

What to measure

Measure the path rather than hours worked. How often do you ship? How long does a change take from start to production? How often does it fail once it is out, and how long does it take to restore service? Cumulative flow shows whether triage piles up faster than build. Cycle time percentiles show the slow tail that an average hides. Compare the team with last month. If review is the slow band, make batches smaller. If Monday starts with an empty Ready column, spend Friday on triage.

How the loop stays one system

As a team grows, each row of that table tends to end up in a different tool. Chat holds requests, an error tracker holds bugs, a doc holds the plan, and a slide holds the roadmap. Each handoff drops a field. You can stay in a general issue tracker and make the fields mandatory, or keep one list where a note, an error, and a chat request become the same kind of ticket. How Falrow runs that delivery loop is one way to do the second: captured work, rules on the ticket, a roadmap counted from those tickets, and a forecast from history you already have. Falrow is in private beta, with access and pricing on request. Either way, the stages only hold if someone sends a ticket back when it skips a column. A meeting note that never becomes a reviewed ticket will be quoted back to you later as a promise.

FAQ

What is a software development workflow?

It is the agreed path from a request to a released change: who decides, what each stage leaves behind, and which check lets the work move on. The path covers intake, triage, ready, plan, build, review, release, and close. Columns without exit checks give you a view of the work, but they aren't a workflow.

How is a workflow different from a project plan?

A project plan says what you intend to ship and roughly when. The workflow says how any single request moves, including bugs and operational tasks that never appeared in the plan. You need both. A plan without a workflow relies on a few people remembering the gates, and a workflow without a plan will process whatever arrived last.

What should a small team write down first?

Start with the ready check, the definition of done, and a rule that requests get captured the same day. Those three prevent the expensive mistakes: building the wrong thing, and calling it finished too early. Add release ownership next, including who watches the first hour and how you roll back.

How do AI coding agents fit without skipping review?

Give the agent a ready ticket and a plan that names files, tests, and risks. Let it write on a branch tied to that ticket. A person still reviews the result against the outcome and the definition of done before it merges. Reject plans that don't match the current tree. The agent can shorten the build stage, but triage, the ready gate, and the release decision still belong to people.