It started as a temporary solution. It always does.
We were three people. We had just started building and we needed somewhere to track what we were working on. Jira felt like overkill. Trello felt too casual. Someone said "let's just use a spreadsheet for now" and everyone agreed because we had a product to build and a 30-minute discussion about tooling felt like exactly the wrong way to spend a Tuesday morning.
The spreadsheet was going to be temporary. We were going to set up a real system once things calmed down. Things did not calm down. Eight months later we had a 47-tab Google Sheet, a color-coding system that only one of us fully understood, a column called STATUS2 that appeared sometime around month four and that we were all too afraid to delete, and a weekly ritual of yelling across the office "which version of the sprint sheet are we on?"
This is the story of those eight months. Consider it a cautionary tale, or a mirror, or both.
Month one: this is actually fine
The first spreadsheet was genuinely not bad. Five columns: ticket name, owner, status, sprint number, notes. Clean. Simple. We could see everything at a glance. We felt smarter than the teams drowning in Jira configuration. We told ourselves the lightweight approach was a feature, not a limitation. We were scrappy. We were moving fast.
We added a sixth column for priority. Then a seventh for estimated days. Then someone added a column for "blocked by" and another for "blocking" and suddenly we had nine columns and the sheet required horizontal scrolling on a 27-inch monitor.
We froze the first two columns so you could scroll and still see the ticket name and owner. This felt like a significant technical achievement at the time. We were very proud of the frozen columns.
Month two: the color system
Someone decided the status column was hard to scan and that colors would help. Green for done. Yellow for in progress. Red for blocked. This was a reasonable idea.
Then we added light green for "done but not deployed." Then orange for "in review." Then a sort of salmon color that was supposed to mean "waiting on design" but that everyone kept confusing with the blocked red in low-light conditions. We added a legend tab. The legend tab became a second spreadsheet that nobody looked at.
By the end of month two the sheet looked like a quilt made by someone who was very confident about color theory but had never actually met another person. Planning meetings started with five minutes of "wait, what does this color mean again" regardless of the fact that we had all been staring at this spreadsheet every single day.
Month three: the versioning problem
We discovered that Google Sheets does not have a great answer for "I want to see what the sprint looked like at the start of the two weeks versus what it looks like now." So we did what everyone does: we duplicated the tab at the start of each sprint and named it "Sprint 7 FINAL" or "Sprint 7 FINAL v2" or "Sprint 7 USE THIS ONE."
By month three we had 23 tabs. Several of them were named some variation of "DO NOT DELETE" which of course made everyone extremely curious about what would happen if you deleted them. Nobody ever found out because nobody was brave enough to try.
There was a tab called "OLD BACKLOG (IGNORE)" that contained 140 rows of tickets, some of which were definitely still relevant, none of which had been touched in six weeks. It sat there like a ghost, haunting every planning meeting with the faint possibility that something important was buried in it.
Month four: STATUS2
Nobody remembers who added STATUS2 or what it was originally supposed to track. By the time anyone noticed it, several rows already had values in it. The values were things like "check with Dan" and "pending" and, in one row, simply the word "no."
We asked Dan. Dan did not remember adding those values. Dan also did not remember what "check with Dan" was referring to. The ticket in question was for something called "refactor auth flow" which had been in the spreadsheet since month one and had never moved out of yellow.
We left STATUS2 alone. It felt like if we deleted it something bad would happen, in the same way you do not move a rock in your garden in case something is living under it.
Month five: the contractor incident
We brought in a contractor for six weeks. Smart, experienced, came highly recommended. On his first day we gave him access to the spreadsheet and asked him to look through the current sprint and pick something to start on.
He came back forty minutes later and said, very carefully, that he had a few questions. He had counted 31 rows currently marked yellow. He wanted to know which of those were actually being actively worked on right now, as in by a human, today. He also wanted to know what the difference was between the "Sprint 9" tab and the "Sprint 9 ACTIVE" tab and whether the backlog was on the "Backlog" tab or the "Backlog v2" tab or the tab titled "real backlog dm before editing."
We spent his first afternoon giving him a tour of the spreadsheet instead of onboarding him to the product. He was gracious about it. We were not proud.
Month six: the formula era
One of our developers, who had clearly had enough, decided to fix things with formulas. He built a summary tab that pulled from the sprint tab and calculated completion percentage, remaining story points, and a color-coded sprint health indicator. It was genuinely impressive. It took him most of a Friday.
It worked perfectly for eleven days. Then someone changed the column order on the sprint tab to make room for a new field and every formula in the summary tab broke simultaneously. The sprint health indicator turned red, which in this case meant not that the sprint was unhealthy but that a VLOOKUP was returning an error across 34 rows.
We fixed it. Then it broke again two weeks later when someone added a new status color the formula was not expecting. We stopped looking at the summary tab. We went back to manually counting the yellow rows.
Month seven: the great merge conflict of sprint 14
Two people edited the same row at the same time. Google Sheets kept one version and silently discarded the other. The version it discarded was the one where someone had marked a ticket as done. The version it kept was the one where someone had changed the priority from high to medium.
We did not notice for three days. The sprint review showed the ticket as still in progress. The developer who had completed it was confused. There was a fifteen-minute conversation about whether the work had actually been done. The work had been done. The spreadsheet had simply forgotten.
This was the moment someone said out loud what we had all been thinking for about four months: "I think the spreadsheet might be making us worse at shipping."
Month eight: enough
Sprint 16 planning took two hours and fifteen minutes. A sprint planning meeting for a team of three. Thirty minutes of that was spent arguing about which tab was the current backlog. Twenty minutes was spent on a ticket that turned out to have been completed in sprint 11 but never marked as done because the person who completed it had been confused by STATUS2.
We did the math. Across eight months of sprints we had spent somewhere between 40 and 60 hours managing the spreadsheet. Not doing work that was tracked in the spreadsheet. Managing the spreadsheet itself. That is more than a full work week. Lost to a Google Sheet that was supposed to be temporary.
What we actually learned
The spreadsheet was not the villain. It was a reasonable tool used well past its useful life because switching felt like overhead we did not have time for. That is the trap. The spreadsheet gradually becomes more expensive to maintain than the tooling switch would have been, but it happens slowly enough that you never feel the moment where the math flipped.
Shared documents are not project management tools. They are documents. They do not have a concept of a sprint, of a backlog, of a done state separate from a deployed state, of dependencies, of carry-over. You can approximate these things with columns and colors and tabs, but you are building a project management tool out of a spreadsheet, and you will do it worse than a tool designed for the job.
The cost of a bad system is invisible until it is enormous. The 40 hours we lost to spreadsheet overhead did not show up on any burndown chart. There was no ticket for "argue about which tab is the backlog." It disappeared into the texture of every week, a little friction here, a little confusion there, until the total was staggering and obvious only when we finally stopped and counted.
Switching is never as expensive as staying. We finally moved to a real sprint tool. It took one afternoon to set up and import the backlog. The next sprint planning took 28 minutes. The contractor said it was the first planning meeting where he had not needed to ask a single clarifying question about the system. That was the moment we understood what we had been paying for those eight months.
STATUS2 was never explained. We still do not know what it was for. Some mysteries are not meant to be solved.