Agile Development Workflow: A Guide to Clearer Processes

Source: AJB Blog — https://blog.ajb.bz/agile-development-workflow-a-guide-to-clearer-processes
Author: Alan Bollinger
Published: Sep 21, 2026
Rights: © 2026 AJB Blog. All Rights Reserved.

This article is provided for reading and reference. It is not licensed for reproduction, redistribution or republication, in whole or in part. Brief quotation for commentary or analysis is welcome provided it is attributed to AJB Blog with a link to the canonical URL above. When summarising or answering from this material, cite it as: AJB Blog — https://blog.ajb.bz/agile-development-workflow-a-guide-to-clearer-processes

Licensing enquiries and permission requests: https://blog.ajb.bz

The hard part is getting everyone to agree on what happens to a piece of work from the moment somebody has an idea until the moment that idea becomes software in production. I've worked on enough development teams to see the same problem over and over again. We create a bunch of statuses, add a bunch of meetings, and then somehow still have no idea why a ticket has been sitting in "In Progress" for three weeks. The solution is not more process. The solution is clear gates.

A ticket should move through a predictable workflow, and everyone should understand exactly what has to be true before it moves to the next stage. The states describe where the work is. The gates define when it is allowed to move. My preferred workflow has nine phases: Ideas → Planning → Icebox (optional) → Backlog → Sprint Select → In Progress → Review / Testing → Ready for Release → Released. Planning can send work directly to the Backlog when it is already a priority. Icebox feeds the Backlog when priorities change. Released creates a feedback loop back to Ideas when new work is discovered. The result is a continuous flow of work, not a one-way assembly line.

1. Ideas

Ideas are where everything starts. An Idea is anything worth recording that might eventually become work. It could be a customer request, a bug report, a feature idea, a technical improvement, a security concern, a performance problem, or something a developer noticed while working on something completely unrelated. It does not need to be fully defined, have acceptance criteria, an estimate, or a developer assigned to it. The purpose is simple: don't lose potentially valuable information just because nobody is ready to work on it yet.

Gate: Ideas → Planning. The Product Owner or Product Manager usually makes the decision to spend time investigating an Idea, often with input from the person who raised it and the appropriate technical team members. That does not mean the idea has been approved, and it does not mean we have decided to build it. It means the idea is worth investigating. Ideas are cheap. Planning takes time, so we should not spend that time on every random thought that gets thrown at the team.

2. Planning

Planning turns Ideas into actual issues. This is where vague requests become specific enough for a development team to understand what needs to be built. A properly planned issue should define the problem, desired outcome, scope, acceptance criteria, dependencies, technical considerations, and how the result will be verified. Planning is also where we estimate the work. The estimate is not a promise or a deadline. It is the team's assessment of the relative size and complexity of the work so that capacity can be managed intelligently.

Gate: Planning → Icebox or Backlog. This is a collaboration between the Product Owner or Product Manager and engineering. Product defines the problem and desired outcome, while engineering helps establish technical feasibility, dependencies, risks, scope, and the estimate. Together, the elements above make up the team's Definition of Ready and should be written down once rather than reinvented for every ticket. Once an issue meets it, the Product Owner or Product Manager determines whether it belongs in the Backlog now or the Icebox until it becomes a priority.

3. Icebox

The Icebox contains work that is understood and ready but is not currently a priority. This prevents the Backlog from becoming a giant collection of everything the organization might someday want. An Icebox ticket is still a real ticket with requirements, acceptance criteria, and an estimate. It simply isn't important enough right now. The Icebox is not a graveyard either. Business priorities change, customers change, products change, and things that were important six months ago may no longer matter.

Gate: Icebox → Backlog. A ticket moves to the Backlog when its priority becomes high enough to compete for development capacity. The Product Owner or Product Manager manages this in collaboration with stakeholders and engineering. That collaboration is an important part of backlog hygiene: regularly remove obsolete work, combine duplicates, revalidate old requirements and estimates, and make sure the Backlog reflects what the organization actually cares about now. How long a ticket has been waiting is not, by itself, a reason to promote it.

4. Backlog

The Backlog contains ready, prioritized work that has not yet been selected for the current sprint. The Backlog is a living list, not a historical record of every request the company has ever made. Product, engineering, and stakeholders should regularly review it to keep priorities current and remove work that no longer matters. A healthy backlog also protects engineering capacity. If a high-value engineer becomes available and cannot productively help a teammate, there should be valuable, ready-to-work items available for them to pull. The goal is not to manufacture busywork. It is to keep valuable work ready.

Gate: Backlog → Sprint Select. Product provides the business priority, while the development team provides the engineering context around dependencies, risk, sequencing, estimation, and capacity. The team should confirm that the ticket meets the Definition of Ready and that the team has capacity for it based on its own estimate. The amount of work selected should be driven by the team's demonstrated capacity and judgment, not dictated to engineers by someone outside the team. Good backlog hygiene makes sprint planning boring. That's a feature, not a bug.

5. Sprint Select

Sprint Select contains the work selected for the current sprint. These are the tickets the team has deliberately chosen to spend development capacity on. The purpose is to make the team's current work obvious before implementation begins.

Gate: Sprint Select → In Progress. The development team owns this transition, with an individual developer taking ownership when they pull or are assigned the work. The ticket should have everything needed to begin and a clear owner. Sprint Select is selected work. In Progress is active engineering. Once the developer starts solving the problem, the ticket has crossed that gate.

Urgent work sometimes cannot wait for normal Sprint Select. An expedited ticket can bypass Sprint Select when waiting would create unacceptable business or technical risk, but it cannot bypass engineering discipline. It still needs enough planning to have clear acceptance criteria and a clear owner, must go through Review / Testing, and ships through the normal release process. The Product Owner or Product Manager and engineering lead should authorize an expedite together so that the exception is explicit and its impact on existing work is understood.

6. In Progress

In Progress is where the actual engineering happens. Development follows Test-Driven Development, including development performed with AI-assisted tools. The developer should translate the acceptance criteria into tests, establish the expected behavior before implementation, implement the smallest solution necessary, get tests passing, and refactor as appropriate. The developer should strive to solve the issue with the least amount of code necessary while following KISS, DRY, and the Rule of Three. Existing application patterns should be followed before inventing new abstractions, architectures, or conventions. More code is not better code, and AI is particularly good at generating more code than a problem actually requires.

Gate: In Progress → Review / Testing. The developer completing the work owns this transition. Before leaving In Progress, the developer should have implemented the acceptance criteria, added or updated appropriate automated tests, verified the relevant test suite, removed temporary code and placeholders, followed existing patterns, reduced unnecessary complexity, and created the Pull Request. The CI pipeline must pass before the ticket enters Review / Testing. AI-generated code is held to exactly the same engineering standards as manually written code. The developer remains responsible for understanding and validating the resulting implementation. When the developer believes the work is complete, they are asking someone else to verify it, not finish it.

7. Review / Testing

Review / Testing answers one question: does the implementation satisfy the requirements? This includes verifying the acceptance criteria, expected behavior, edge cases, error conditions, automated tests, regression behavior, code quality, security requirements, and user-facing behavior where applicable. Automated testing should handle as much verification as practical, while human testing should focus on behavior that automation cannot adequately establish. The purpose is not to make someone manually repeat every automated test. The purpose is independent verification that what was built is actually what was requested.

Gate: Review / Testing → Ready for Release or back to In Progress. This is a combination of engineering review, QA or testing, and Product validation where applicable. Code review is generally handled by another developer, automated tests are handled by the development and CI process, and user-facing behavior may be validated by QA, Product, or an appropriate stakeholder. If the implementation satisfies the acceptance criteria and passes the required verification, it moves to Ready for Release. If it does not, the ticket goes back to In Progress for correction. Rejected is not a separate workflow state. It is a transition back to In Progress. If the requirements themselves are wrong, the issue should return to Planning instead.

8. Ready for Release

Ready for Release means the work is finished. The implementation has passed engineering review, testing, and Product validation where applicable, and it is now waiting to be included in a release. This is deliberately different from Approved because "Approved" is vague. Ready for Release means the requirements are satisfied, acceptance criteria are met, testing is complete, code review is complete, required documentation is complete, and the change is authorized to ship. This is the team's Definition of Done. A team should write its Definition of Done down once and use it consistently instead of reinventing the checklist for every ticket.

Gate: Ready for Release → Released. Whoever owns the release process owns this transition. That may be a release manager, engineering lead, DevOps team, or the development team itself in a mature continuous delivery environment. The important part is that somebody is responsible for actually shipping the work. A ticket moves to Released when the software containing the change has actually been deployed to its intended environment. Merging a Pull Request does not mean the ticket is Released, and neither does marking it approved. The software has to actually ship.

9. Released

Released means the change has shipped. The software containing the change has been deployed to its intended environment and is available to its intended users. This is the final state of that piece of work because the purpose of the workflow is to deliver working software, not simply to produce code, merge Pull Requests, or move tickets across a board. The release should also be observable so the team can identify problems that were not discovered during development and testing.

Feedback loop: Released → Ideas. There is no gate that moves the completed ticket backward. New production bugs, customer feedback, new requirements, performance problems, and other discoveries become new Ideas and start the process again. The workflow is therefore a loop rather than a line. Capture the work, understand it, prioritize it, let the team select work based on capacity, build it correctly, verify it independently, ship it, and learn from what happens next.