I used to hit this wall almost every other Friday. The sprint was ending, stakeholders were waiting, and somebody on the team would ask the same question: “What did we work on this sprint?” We had been busy. We had been heads-down for ten days. We had closed tickets, merged branches, sat through stand-ups. But when it was time to demonstrate value, the details scattered. The work felt like a single gray smear.
That is the blur. Memory is not the problem. Visibility is.
The blur shows up in smaller moments too. Somebody asks in daily scrum, “What did you do yesterday?” and the answer comes out thin. You know you did something. You probably did several somethings. But the specific thread you were pulling, the decision you made, the problem you untangled, none of it is at your fingertips. By Monday, after a normal weekend, Friday is already hazy.
I have come to dislike that sensation. I do not want to look back at two weeks of my life and see only blurred days. I want to see the shape of the work. I want to remember what I learned, why it mattered, and what I should do differently next time.
The Opaque Stream
The blur happens because I used to treat my own work as an opaque stream of tasks. A card moves to “In Progress.” Code is written. The card moves to “Done.” Repeat. The board tracks motion, but it does not capture meaning. It does not record the conversation where we realized the API contract was wrong. It does not keep the whiteboard sketch that explained the domain model. It does not hold the question I meant to ask the product owner but forgot.
A task board is a useful coordination tool. It is a lousy memory tool.
When the sprint ends, the board tells me what got moved. It does not tell me the story of why we moved it, what we discovered along the way, or what we should carry into the next sprint. That story lives in scattered places: a Slack thread, a notebook page, a screenshot on my desktop, the whiteboard that got erased on Thursday. By Friday, most of those traces are gone.
AI Makes the Blur Sharper
I wrote recently about Driving, Flying, and the Speed of AI and the idea that speed is only valuable if we are moving on the right plane. AI coding tools are like switching from driving to flying. You cover much more ground in the same amount of time. But if you are not keeping track of where you are going, you end up farther from where you meant to be, much faster.
The same thing is happening inside sprints. AI compresses execution time. It can generate scaffolding, tests, boilerplate, and entire features in hours that used to take days. That is a genuine advantage. But it also means the gap between “what I did” and “what I understand” can widen before I notice. The work moves faster than my memory can keep up.
I prefer to think about AI in my loop, instead of human in the loop. I own the workflow. The AI is a tool inside it. If I do not have a practice for capturing context as I go, the AI becomes a very fast way to create work I will struggle to explain later.
The same tension shows up in Time, Presence, and the Speed We Choose. The speed we choose depends on the space we leave. If I fill every hour with output and leave no space for capture and reflection, I am choosing speed without presence. That is how the blur becomes normal.
Why the Blur Hurts
The blur costs us at demo time, when we need to show value and not just velocity. It costs us at the retrospective, when we try to learn from the sprint but cannot reconstruct it. And it costs us again in the next sprint, when we run into a problem we solved two weeks ago and have to solve it twice because nobody wrote down how we got there.
It also costs something personal. I have had performance conversations where I could not articulate what I had done beyond “I completed my stories.” That is a bad place to be. It is also unnecessary. The work is there. The learning is there. I just had not built a habit of making it visible.
What Changed My Mind
The shift started with a simple question: If I would not accept an opaque stream of tasks from a team I am coaching, why was I accepting it from myself?
We spend much of our professional energy preaching transparency, inspection, and adaptation to clients and teams. We want the board visible, the backlog inspected, the process adapted. Those are Scrum values, and they are good values. But I was applying them only at the team level and not at the individual level. My own work was the one place where I allowed the blur to live.
That realization led to a personal practice I will describe in the rest of this series. The point is not the tool. I have used Lotus Organizer, Schedule+, Outlook, OneNote, Evernote, and now Obsidian. The tool changes. The habit matters. The habit is this: treat every sprint as something worth documenting while it is happening, not reconstructing after it is over.
A Series About the Habit
This is the first of six posts about how I document my sprints. The next one will lay out what a personal Scrum looks like when the team is just me. After that I will show the actual note template I use in Obsidian, then the daily breadcrumbs that keep me oriented through interruptions, then how the notes feed sprint reviews and retros, and finally how those same notes become career capital.
If your sprints already feel clear and reviewable, this series may not be for you. But if you have ever stood in front of a screen on a Friday and wondered what you actually did with the last two weeks, you are the person I am writing to.
Speed without context is just motion. Slowing down is not the counterweight. Making the work visible as I go is.
Leave a Reply