At some point in early 2024 our Jira board became a work of fiction.
Not immediately, and not dramatically. It happened the way most dysfunction on small teams happens: gradually, quietly, and through a series of individually reasonable decisions that collectively added up to something absurd.
On paper, we had a real system. We had Jira. We had a configured board with custom statuses. We had epics and stories and sub-tasks and a backlog that someone had spent a meaningful amount of time setting up correctly. We had a sprint cadence. We had standups. From the outside, we looked like a team that had its process together.
From the inside, the board had approximately zero relationship to what anyone was actually working on. But we kept the standups. We are nothing if not committed to the ritual.
How a board dies
It does not happen in one moment. There is no single decision where someone says "you know what, let us just stop updating Jira." It erodes, ticket by ticket, update by update, until the gap between what the board says and what is actually happening becomes too embarrassing to acknowledge and too large to close in a single session.
In our case it started with notifications. Jira's default notification settings, if you have not met them, are enthusiastic. Aggressively enthusiastic. Every comment, every status change, every assignment, every update to an issue you are watching sends an email. Within two weeks of setting up our Jira, every developer had created a filter to send all Jira emails directly to a folder they never looked at. The notifications had become noise, and so the mechanism by which people knew to look at the board had been neutralized.
With the notifications muted, ticket updates stopped feeling urgent. If nobody was going to see it anyway, updating the status felt like a bureaucratic exercise with no recipient. So people stopped doing it as frequently. Status updates went from daily to every couple of days to "when I remember" to, for one developer who shall remain nameless, a once-per-sprint bulk update the morning of sprint review where he moved everything he had worked on from "In Progress" to "Done" in a single satisfying sweep that bore no relationship to when any of the work had actually been completed.
This was not malicious. It was human. If the system is not providing value in the moment of updating it, people stop updating it. The system stops reflecting reality. And once a system stops reflecting reality, people stop looking at it to understand reality. They ask each other instead.
The shadow sprint
By about month three of this slow deterioration, the team had developed what I can only describe as a shadow sprint. The official sprint existed in Jira. It had 18 stories, various statuses, a burndown chart that showed a line moving at an angle that would have implied we were mostly on track if you did not look too closely.
The actual sprint existed in people's heads, in a pinned Slack message that one of the developers updated every Monday morning, and in a recurring Wednesday check-in where we went around and said what we were working on and what was blocked. The Slack message was more accurate than Jira. The verbal check-in was more accurate than the Slack message. The most accurate representation of what the team was working on at any given moment existed solely inside the heads of the three people doing the work.
We had paid for Jira, configured Jira, maintained Jira, and trained on Jira. And we were running our actual sprint in a pinned Slack message and collective memory.
The sprint review that broke us
We brought in an advisor for a quarterly check-in. Smart, experienced, someone who had built and scaled a couple of teams before. She asked if she could look at the board before we discussed how the quarter had gone.
There was a pause. Not a long pause. Maybe three seconds. But three seconds is a long time when a question has been asked and nobody wants to be the first to say the thing.
What followed was a fifteen-minute conversation that I would describe as gently devastating. She asked about a story that had been In Progress for 34 days. She asked why three stories from the previous sprint were still marked as In Progress when we had verbally told her they were done two weeks ago. She asked what the "HOLD" status meant because she did not see it in the workflow documentation. (We had added the HOLD status around month two. Nobody had documented it. It meant something slightly different to each of us.)
She did not say the board was bad. She just kept asking questions that we could not answer from the board. Every answer required one of us to translate: "that one's actually done, we just haven't updated it," or "that's been on hold because of the API dependency, it's in a Slack thread," or "I'm not sure who owns that one right now, I think Dan picked it up but he's been working on something else."
After about the fifth translation she put her laptop down and said: "It sounds like the team is doing good work. The system is just not capturing it. That's going to become a problem as you grow."
She was being kind. The system was already a problem. We just had not admitted it.
The autopsy
After she left we did something we had not done in months: we sat down and looked at the board honestly. Not to update it, not for a planning meeting, just to understand how far from reality it had drifted.
Of the 22 stories in the current sprint, 7 were marked In Progress and actually in progress. 4 were marked In Progress and actually done. 3 were marked In Progress and actually blocked waiting on something external. 2 were marked To Do and had actually been started. 1 was marked Done and was not done. The remaining 5 were in various states of accuracy.
The backlog was worse. There were 94 stories in it. We went through them. 31 were still relevant and correctly prioritized. 24 were relevant but hadn't been touched in so long that the original context was gone and someone would have to rewrite them from scratch before they could enter a sprint. 19 were for features that we had decided not to build. 12 were duplicates of other tickets. 8 were so vague that nobody could remember what they had originally meant. The last one, ticket number 94, was titled "the thing Tom mentioned" with no description, no owner, and no comments. Tom had left the company four months earlier.
We had been maintaining an illusion of a functioning system while actually running on informal communication and collective memory. It had worked, mostly, because we were small and co-located and talked to each other constantly. It would have collapsed the moment we hired anyone new, went remote, or had more than one sprint of complexity to track.
What we changed
The root issue was not that we had Jira. The root issue was that Jira's friction-to-update ratio was high enough that people stopped updating it the moment the immediate social pressure to do so relaxed. The configuration was complex enough that making changes required someone with admin knowledge. The notification system had been so aggressive that everyone had trained themselves to ignore all signals from the tool. And the backlog had been allowed to grow into something so large and ungroomed that engaging with it felt like a project in itself.
We needed a system where updating a status took two seconds, not six clicks. Where the backlog was maintained as a matter of default, not as a special grooming session. Where a new person could look at the board and understand the sprint without a guided tour. Where the tool was working for the team rather than the team working around the tool.
We archived 63 backlog tickets in one sitting. It took an hour and felt like cleaning out a closet that had been filling up for two years. The remaining 31 tickets were rewritten with clear titles, descriptions, and acceptance criteria. The sprint was cleaned up to reflect actual reality. The HOLD status was documented and then, after a brief debate, removed entirely because none of us could agree on a definition that was meaningfully different from "blocked."
The first standup after the reset took eight minutes. Usually they ran to twenty-five because half the time was spent figuring out what anyone was actually working on versus what the board said they were working on. Eight minutes. We talked about the work, not about the system.
The thing we actually learned
A project management tool only works if the team uses it, and the team only uses it if using it is easier than not using it. This sounds obvious written down. It was not obvious to us while we were living it, because we were inside the slow drift and could not see clearly how far the board had moved from reality.
The warning sign, in retrospect, was the moment we started translating. When someone asks about the board and your answer is "well, that ticket actually means..." or "we're tracking that in Slack instead..." or "that one's complicated, let me explain" -- that is the moment the board has stopped being a source of truth and become a liability. The board should answer questions, not generate them.
"The thing Tom mentioned" was eventually figured out. It was a feature suggestion about how we handled pagination on a particular screen. Tom had been right. We built it six months later. We gave the ticket a proper title.