Picture a Tuesday six months from now. You open a file and find a check that makes no sense: stories older than ninety days are skipped during import, silently. It looks like a bug. You run git blame and find the commit. The message reads "Skip stale stories during import (adds age filter, updates tests)". Accurate, tidy, and it tells you nothing about why.
Was a customer's import timing out? Was it a deliberate product decision? Did someone ask for it, and are they still around? If you remove it, what breaks, and for whom?
That scenario is not new. What is new is how often it is going to happen. When a coding agent writes a good share of your code, fewer of the decisions behind that code were ever sitting in anyone's head. So the question I keep coming back to is: where does the why live now? My answer, and the one this post defends, is the board.
Git remembers what. It was never good at why.
I love git. It is the most reliable record most teams have, and nothing here is an argument against it. But it records changes, not decisions, and the gap between the two is getting wider.
Commit messages were always a patchy source of reasoning. People wrote "fix" and "wip" and "address review comments". Agent-written commits are actually more consistent than that, which makes them feel more trustworthy than they are. They describe the diff beautifully: what was added, what was renamed, which tests changed. What they cannot describe is the conversation that led to the request, because the agent was never in it.
And some of the most useful history never produces a commit at all. The feature you discussed for a week and decided not to build. The approach you tried in a spike and threw away. The customer request you parked because it clashed with something bigger. None of that is in git log. Six months later, someone (quite possibly an agent) will cheerfully propose the same idea again, and nobody will remember why it was a bad one.
I will concede one thing. If your team writes thorough pull request descriptions and links every discussion, you have a lot of this already. But PRs are organised by change, not by intent, they are scattered across repositories, and a stakeholder is never going to go and read them. A board is organised around the thing people actually ask about: this piece of work, and why we did it.
What the board adds that nothing else does
A story that has been used properly carries three kinds of history, and each answers a different question later.
The original intent answers "what were we trying to do?" This is the description and acceptance criteria as they stood when work started. It is also why writing stories with real detail pays off twice: the same text that briefed the agent is the record of what you asked for.
The timeline answers "when, and who?" When was this picked up, which sprint did it land in, who changed the scope and on what day. You should never have to write this by hand. In Scrumpy every story keeps an activity history automatically: status changes, story points, assignee, sprint and epic changes, each with who did it and when. Edits to the description, acceptance criteria and test notes are grouped into one entry per editing session with the before and after, so you can see exactly how the requirements shifted without wading through every keystroke.
The discussion answers "why did it end up this way?" The comments where someone said "actually, let's only do this for imports from Jira" are the most valuable sentences in the whole project, and they belong on the story, not in a chat thread that scrolls away by Friday. When a thread gets long, Scrumpy's assistant can summarise the discussion so the next person catches up without reading forty comments.
Put those three together and the Tuesday scenario ends very differently. The story shows who asked for the filter, the comment explains that ninety-day-old Jira exports were blowing up imports for one large customer, and the history shows the scope was narrowed twice before it shipped. Five minutes, and you know whether the check is safe to remove.
How to keep the record when agents do the work
None of this requires ceremony. It requires a few habits, and they are all small.
Start every change from a story. Even a short one. If the work is worth handing to an agent, it is worth one line in the backlog saying what and why. That is the anchor everything else hangs from.
Link the code to the story. Put the story reference in the branch name, so anything in git leads back to the reasoning. If you connect a repository in Scrumpy, it generates the branch name for a story from your own naming format, including the story's reference, so nobody has to remember the convention.
Write decisions down where the work lives. When you change your mind mid-story, add a comment saying so and why. The chat with the agent where you realised it is gone the moment you close the window. The comment is still there next year.
Let the agent report back. This is the habit I like most. The Scrumpy API can create and update stories and post comments with a team API key, so a small script at the end of an agent run can add a note to the story: what changed, what it was unsure about, what it deliberately left alone. The request and the answer end up side by side.
Close things honestly. When you decide not to build something, don't just delete the story. Say why in a comment and move it out of the way. The rejected ideas are exactly the history you will want when they come back.
Why this matters more for small teams
It is tempting to think all this is big-company process. It is the opposite. A large company has people whose job is to remember: product managers, architects, the engineer who has been there nine years. A two-person team or a solo developer has nobody like that. Your memory is the only record, and when an agent wrote the code, your memory of it is thinner than it would have been if you had typed every line.
So yes, as work gets more automated, I think the scrum board earns its place more than it used to. Not as a way to tell people what to do next (the agent does not need a standup) but as the one place the whole story of the product is written down: what you asked for, when, who decided, and why. If you would like that record to build itself while you work, Scrumpy keeps it on every story from the first day, and you can try it on your next feature without a card.
Frequently asked questions
Do small teams still need a scrum board if AI does most of the coding?
Yes, though the reason shifts. Less of the board's value is coordinating who types what, and more of it is keeping a durable record of what was decided, why, and when. When agents write much of the code, that reasoning is no longer in anyone's head by default, so it has to live somewhere the whole team can find it.
Isn't git history enough to know why code was written?
Git reliably records what changed and when, but it is a poor record of why. Commit messages describe changes rather than decisions, agent-written commits tend to summarise the diff rather than the reasoning, and ideas that were discussed and rejected never produce a commit at all. A story with its discussion and history fills that gap, and linking the two, for example through branch names that include the story reference, gives you both.
What should a story record so it is useful months later?
The original problem and who asked for it, the acceptance criteria as they were when work started, any change of direction with the reason, and a short note on what actually shipped. A tool that keeps a history of status changes and edits adds the when and the who automatically, so the team only has to write down the reasoning.
How can a coding agent contribute to the project history?
Point it at the story before it starts and have it report back to the story when it finishes. With an API that can post comments, an agent or a small script can add a summary of what it changed, which files it touched and anything it was unsure about, so the reasoning sits next to the original request instead of in a chat log nobody will find.
