Understanding the Issue Lifecycle #3
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: AgileTransformation/AgileAdoption#3
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Understanding the Issue Lifecycle
🤔 What is an "Issue"?
Think of an "issue" like a task card or a to-do item. It could be:
Just like a package moving through a delivery system, every issue goes
through several stages from start to finish. Let's walk through each
stage!
✅ The Main Journey
Backlog
The Waiting Room
👤 Who's Responsible?
Tech Lead / Product Owner
📍 What Happens Here?
All new ideas and problems arrive here first. They're waiting to be
reviewed and prioritized.
🎯 When Does It Move Forward?
💡 Real-Life Analogy
Think of a restaurant's order ticket board. When customers place
orders, they all go on the board first. The chef looks at all orders and
decides which ones to cook next based on time, complexity, and
importance.
📝 Example
Someone reports: "The login button doesn't work on mobile phones."
This report lands in the Backlog. The Tech Lead reviews it, confirms
it's a real problem, marks it as "high priority," and adds a label
"bug" and "mobile."
Todo
Ready to Start
👤 Who's Responsible?
Tech Lead (assigns the work)
📍 What Happens Here?
The issue is approved and ready to be worked on. It's been prioritized
and all questions have been answered.
🎯 When Does It Move Forward?
💡 Real-Life Analogy
Like a line of passengers at an airport check-in counter. Their tickets
are ready, they have all documents, and they're just waiting for the
next available agent to help them.
📝 Example
The Tech Lead assigns the mobile login bug to Sarah, a developer who
specializes in mobile issues. Sarah sees it in her Todo list and knows
she'll work on it next.
In Progress
Work is Happening
👤 Who's Responsible?
Developer (the person actually doing the work)
📍 What Happens Here?
The developer is actively writing code, fixing the bug, or building the
new feature.
🎯 When Does It Move Forward?
work)
💡 Real-Life Analogy
Like a mechanic actively working on your car. They've got it on the
lift, they're underneath it with their tools, fixing the problem. You
can't drive it yet, but work is definitely happening.
📝 Example
Sarah spends 3 hours investigating the mobile login bug. She discovers
the button code doesn't work properly on small screens. She rewrites
the code to fix it and tests it on her phone.
Dev Completed
Code Review & Approval
👤 Who's Responsible?
Developer + Reviewer (another team member checks the work)
📍 What Happens Here?
Other developers review the code to make sure it's good quality, safe,
and solves the problem correctly.
🎯 When Does It Move Forward?
💡 Real-Life Analogy
Like a writer finishing their article and sending it to an editor. The
editor reads it, checks for mistakes, suggests improvements, and then
approves it for publication if everything looks good.
📝 Example
Sarah submits her fix for review. John, another developer, checks her
code. He suggests one small improvement. Sarah makes the change, John
approves it, and the code is merged into the project.
Ready for Testing
Available in Test Environment
👤 Who's Responsible?
DevOps / Developer (deploys to test area) → QA picks it up
📍 What Happens Here?
The fix is now available in a special testing environment where QA
(Quality Assurance) testers can try it out without affecting real users.
🎯 When Does It Move Forward?
💡 Real-Life Analogy
Like a new car that's finished being built and is now in a test track.
Professional testers drive it around, try all the features, check the
brakes, test the AC, everything---before it goes to customers.
📝 Example
The mobile login fix is now available on the test website. Maria from QA
tests it on 5 different phones (iPhone, Samsung, etc.), tries logging in
different ways, and checks if everything works smoothly.
Done
Tested, Verified, Complete! 🎉
👤 Who's Responsible?
QA validates → Tech Lead closes the issue
📍 What Happens Here?
Testing passed! The issue is verified as complete and can be marked as
finished. It's ready to go to real users.
🎯 What's the Final Step?
💡 Real-Life Analogy
Like getting a package delivered to your door. It started at the
warehouse (Backlog), got packed (Todo), shipped (In Progress), arrived
at your local post office (Dev Completed), went out for delivery (Ready
for Testing), and now it's at your doorstep (Done)!
📝 Example
Maria confirms the mobile login works perfectly on all phones. She marks
it as "testing passed." The Tech Lead closes the issue. The fix goes
live on the website, and now all users can log in successfully from
their phones!
⚠️ When Things Don't Go As Planned
Not everything goes smoothly! Sometimes issues need to go backward or
take a different path. Here are the common situations:
🔴 Blocked
Work can't continue right now
What's Going On?
The developer is stuck and can't move forward because they're waiting
for something:
💡 Real-Life Analogy
You're building IKEA furniture but realize you're missing a crucial
screw. You can't finish until you get that screw, so the project is
"blocked" until you go back to IKEA or order the part.
What Happens Next?
The issue stays in its current stage with a "blocked" label. Once the
blocker is resolved, work continues from where it stopped.
🟡 Failed Testing
The fix doesn't work correctly
What's Going On?
The QA tester tried the fix and found problems:
💡 Real-Life Analogy
You order a burger with no onions, but when it arrives, there are
onions. The kitchen needs to remake it. The order goes back to the chef
(developer) to fix it properly.
What Happens Next?
The issue goes back to "In Progress" stage. The developer fixes the
problems and the whole process starts again (review → testing → done).
🟠 Reopened
The problem came back!
What's Going On?
The issue was marked "Done" and went to production (real users), but
then:
💡 Real-Life Analogy
You had your car fixed for a weird noise, drove home, and the noise is
back. You call the mechanic and say "I need to bring it back---the
problem isn't fully fixed." They reopen your repair ticket.
What Happens Next?
The issue gets a "reopened" label and goes back to "Todo" stage. It
needs to be worked on again from scratch with a fresh look at what went
wrong.
🔵 Needs Information
Important details are missing
What's Going On?
The team can't work on this because they don't have enough
information:
💡 Real-Life Analogy
You call a pizza place and say "I want a pizza." They ask "What size?
What toppings?" Until you provide those details, they can't make your
pizza. Your order is on hold.
What Happens Next?
The issue is put "on hold" in the Backlog. Once someone provides the
missing information, it can move forward to Todo again.
⚫ Won't Fix / Invalid
We're not doing this
What's Going On?
After reviewing the issue, the team decides not to work on it:
💡 Real-Life Analogy
Someone requests that a coffee shop add a full dinner menu. The owner
says "We're a coffee shop, not a restaurant---we won't be doing
that." The request is closed as "won't do."
What Happens Next?
The issue is closed immediately from Backlog with an explanation of why
it won't be fixed. It never moves to Todo.
🟣 Duplicate
This already exists!
What's Going On?
Someone reported the same problem or requested the same feature that's
already in the system:
💡 Real-Life Analogy
Two people in an office both send an email to IT saying "The printer is
broken." IT replies to the second email: "Thanks, but we already
received this report and someone is fixing it (see ticket #1234)."
What Happens Next?
The duplicate issue is closed immediately with a link to the original
issue. Everyone follows the original issue for updates.
🎯 Key Takeaways
completion
Dev Completed → Ready for Testing → Done
prioritize, Developers build, QA tests
testing, or need to be reopened
invalid, some won't be fixed
priority of each issue
descriptions keep everyone informed
problems are truly solved