When designing a Jira workflow, most people focus on moving issues forward—from “To Do” to “Done” as quickly as possible. But what about when things don’t go as planned? Sometimes, work needs to move backward before it can progress. Steps like “Not Approved,” “Reopened,” or “Needs Changes” aren’t just obstacles—they’re essential for maintaining quality, accountability, and flexibility in your process.
In this post, we’ll explore why backward steps are crucial in a Jira workflow and how to implement them effectively.
Why You Need Backward Steps
1. Ensuring Quality and Accuracy
Mistakes happen. Whether it’s a code review, a design approval, or a compliance check, having a step to move issues back to a previous stage allows teams to catch errors before they cause bigger problems.
🔹 Example: A developer submits code for review, but the reviewer finds issues. Instead of forcing an approval, the issue moves back to “Needs Changes” so fixes can be made before merging.
2. Handling Approvals and Rejections
Not every task gets a rubber stamp the first time. Adding statuses like “Not Approved” or “Changes Requested” ensures that feedback is addressed properly.
🔹 Example: A marketing campaign goes through an approval step, but the VP requests revisions. Instead of the team assuming approval, the issue moves back to “In Progress” for updates.
3. Managing Unexpected Issues
What happens when a bug marked “Done” turns out to be not actually fixed? Without a way to reopen issues, teams might lose track of problems, leading to frustrated users and extra work down the line.
🔹 Example: A support ticket is marked resolved, but the customer reports the same problem. A “Reopened” status helps track these cases properly.
4. Improving Transparency and Accountability
Backward steps create a clear audit trail. Instead of issues mysteriously reappearing in a backlog, everyone knows exactly why something moved backward and who needs to act on it.
🔹 Example: If a product manager rejects a feature for not meeting requirements, Jira logs the transition so the team knows why and what needs to be addressed.
Best Practices for Implementing Backward Steps
✅ Keep It Structured, Not Chaotic
Backward steps should be intentional—avoid endless loops where issues bounce around without clear ownership. Use transitions with:
- Clear criteria (e.g., “Requires additional testing” before moving back to QA)
- Limited permissions (e.g., only reviewers can send tasks back to “Not Approved”)
- Automation (e.g., automatically notify assignees when an issue moves backward)
📊 Use Workflow Triggers to Automate Rework
Jira’s automation can help streamline backward steps:
- Auto-assign issues that move back to “Reopened.”
- Add a comment or tag when an issue moves to “Changes Requested.”
- Require a reason field when sending an issue backward.
🔄 Make It Visible on Your Boards
Backward steps shouldn’t be hidden. Configure your Jira board so statuses like “Needs Changes” or “Reopened” appear clearly—this helps teams stay aware of work that needs attention.
📈 Review and Optimize Over Time
Track how often issues move backward and why. If things keep getting sent back, it might signal:
- A training gap
- Unclear requirements
- A need for process improvement
Use Jira’s reporting tools to analyze trends and make data-driven improvements to your workflow.
Final Thoughts
Backward steps aren’t signs of failure—they’re an essential part of a healthy workflow. They ensure quality, prevent issues from slipping through the cracks, and create transparency. By designing your Jira workflow with intentional steps for rework, you set your team up for long-term success.
How does your team handle rework in Jira? Let’s discuss in the comments!
Leave a Reply