Three days before sprint end, my manager sent a message asking if I was active on the project.
I had spent that sprint building the authentication service. Tests written. PR reviewed, revised, and merged. A walkthrough with QA so they knew what edge cases to watch. I had been heads-down and genuinely productive.
But on the dashboard, my name was on one open ticket.
The auth story had moved to "In Testing" and reassigned to QA. A bug fix had been closed under the QA lead's name after they caught something in review. A debugging session I ran with a junior dev never had a ticket at all. On the board, it looked like I had barely touched the sprint.
Nobody was doing anything wrong. QA followed the workflow. My manager answered a real question from stakeholders. The system did exactly what it was designed to do.
It was not designed for developer visibility after handoff.
This is one of the more reliable patterns in hybrid agile-waterfall teams. The sprint board tracks story status, not developer contribution. The moment your work moves to QA, your name disappears from the ticket. The ticket closes under someone else's name, or sits in a testing queue for days. Mid-sprint, the board shows you as idle while you are doing your most valuable work.
The fix is structural, not philosophical.
Before you write a line of code, create a development subtask on the parent story, assigned to you. Link your PRs and review notes there. When the parent ticket moves to QA, the subtask stays on your name. When someone asks what you shipped this sprint, one click answers the question.
It takes about two minutes per story. It does not change QA's workflow. And it means the work you did is legible to anyone who looks at the board - including your manager's manager who sees a dashboard summary they never knew you knew about.
Every team I have tried this with had the same reaction: curiosity, then mild irritation that nobody had done it sooner.
The visibility problem in most enterprise agile shops is not a performance problem. It is an information architecture problem. The team is building software. The workflow was designed to track tickets.
Those are not the same thing.
If this resonated, I wrote the field guide for it: Surviving Agilefall.
Top comments (0)