From Spreadsheet Chaos to GitHub-Native Project Management

For years, the team in this example ran delivery out of a shared spreadsheet. It worked—until it didn’t. This is the story of how a small product squad moved to github-native project management, where the source of truth for work lives next to the code instead of in a tab nobody trusts. The shift wasn’t a tooling fad; it was a survival decision after one too many “wait, which version is current?” moments.

The spreadsheet that ate the team

Picture a composite eight-person team: four engineers, two QA testers, one manager, and a delivery lead. Their planning lived in a tracking sheet with columns for ticket, owner, status, PR link, and a notes field that had quietly become a graveyard of half-finished thoughts.

The problems compounded:

• Two sources of truth. A pull request might be merged on GitHub while the spreadsheet still said “in review.” Nobody could tell at a glance which one was right.
• Manual copy-paste. Every PR link, status change, and reviewer note was typed by hand. Stale data was the default state, not the exception.
• Invisible QA. Testers worked in GitHub but reported status in the sheet, so their work was perpetually one refresh behind reality.
• No history. When a cell changed, the previous value vanished. Post-mortems became archaeology.

The manager described it bluntly in a retro: “We spend more time maintaining the map than walking the territory.”

What github-native project management actually means

When this team evaluated alternatives, they kept hitting tools that sat beside GitHub and asked you to mirror everything by hand—exactly the problem they already had. What they wanted was a workspace that treated GitHub as the system of record, not a place to copy links from.

The model they landed on with KazTrack worked like this:

1. Repositories, pull requests, and issues are scoped per project and read live from GitHub. No re-entry.
2. Workflow states map to real GitHub labels. A card moving from ready_for_testing to in_progress to passed or failed changes the label on the actual PR—and a label changed on GitHub flows back into the workspace.
3. Comments post to the real GitHub PR. A QA note written in the dashboard shows up as a comment on the pull request, where the author actually reads it.

That last point mattered more than anyone expected. The team’s engineers never had to “check the other tool.” Their feedback loop stayed in the place they already lived.

The first two weeks

Migration was less dramatic than feared, mostly because there was little to migrate—the truth was already in GitHub. The team connected their repositories, set up a project, and defined four workflow states mapped to labels:

ready_for_testing  →  label: ready-for-testing
in_progress        →  label: qa-in-progress
passed             →  label: qa-passed
failed             →  label: qa-failed

The spreadsheet stayed open for a week as a safety net. By day ten, nobody had touched it. The delivery lead archived it with a small amount of ceremony.

What changed day to day

• Standups got shorter. Instead of reconciling the sheet against GitHub, the team read one board that was already in sync.
• QA became visible. When a tester moved a PR to failed, the label appeared on GitHub instantly and the author saw the comment in context.
• Status was trustworthy. Because labels round-trip automatically, “what the board says” and “what GitHub says” were finally the same sentence.

The unexpected wins

A few benefits showed up that weren’t on the original wishlist.

Granular roles replaced honor-system permissions. The old spreadsheet had no access control—anyone could overwrite anything. With role-based access (owner, manager, tester, viewer, plus custom roles), the delivery lead could give stakeholders read-only visibility without risking accidental edits.

Multi-project structure ended the tab sprawl. The team ran two products. Previously that meant two spreadsheets and a lot of context-switching. Now each project had its own scoped repositories, issues, sprints, and milestones under one workspace, with team invites handled per project.

Sprints and milestones lived with the work. Planning artifacts weren’t a separate document to keep in sync; they were attached to the same repositories and PRs the team shipped from.

A practical migration checklist

For teams considering the same move, this is the sequence that worked in the example:

1. Connect repositories first. Get the live PR and issue data flowing before touching process.
2. Define workflow states as labels. Agree on four states and the exact label names. Keep them few and obvious.
3. Run dual-track for one week. Keep the spreadsheet open but read-only as a confidence check.
4. Move QA in early. Testers feel the benefit fastest, so their buy-in accelerates everyone else’s.
5. Set roles before you invite stakeholders. Decide who edits and who only views.
6. Archive the spreadsheet on purpose. A clean cut-off prevents a slow drift back to old habits.

Key takeaways

• Spreadsheets fail at project management because they create a second source of truth that immediately falls out of sync with GitHub.
• Github-native project management keeps the source of truth next to the code: PRs, issues, and workflow states read and write to GitHub directly.
• Workflow states mapped to GitHub labels—syncing both ways—mean the board and the repository never disagree.
• QA visibility, trustworthy status, and granular roles were the highest-impact gains in this composite team’s experience.

If your delivery already lives on GitHub, your project management probably should too. KazTrack gives engineering teams a github-native workspace where the board and the code finally tell the same story—worth a look if your spreadsheet has started eating your week.