I tell teams that transparency, inspection, and adaptation matter. I should hold myself to the same standard. The values are the same. Only the scale changes.
That is the personal Scrum I mean. It is not a certification or a framework with rules and roles. It is the habit of applying three Scrum ideas to my own work so the blur I described in the last post does not win.
The Team-Level Mirage
At the team level, we are good at the ritual. The board is up. The daily scrum happens. The retro is on the calendar. We preach transparency to our clients. We inspect the backlog. We adapt the process. But when I look at my own desk, my own screen, my own calendar, those same values often disappear.
My own work used to look like this: tasks flowed in, I executed them, tasks flowed out. I was busy, but I was not inspectable. I could not tell you, on any given Thursday, what I had learned that week. I could not point to a decision and say why we made it. I could not reconstruct a conversation without digging through three apps.
That is the mirage. The team looks organized, but the individual is still flying blind. And if every individual on the team is flying blind, the team is not as transparent as it thinks it is.
Three Personal Goals
When I started treating my own work with the same care I ask teams to show, I focused on three things.
Clarity. I want to know what I am working on, why it matters, and what I am learning as I go. Not once a week in a status meeting. Every day.
Retention. I want the lessons of this sprint to survive into the next one. If I spend two days solving a problem and then forget the solution, I have paid the tuition without getting the degree.
Accountability. If I tell a product owner I will look into something at the sprint review, I need a place to record that commitment. If I cannot produce it two weeks later, I am either unreliable or I am asking my memory to do work it was never designed to do.
Capturing the Right Things
The first shift was deciding what to capture. A task board holds tasks. I needed something that held context.
I started writing down the conversations. Not every word, but the decisions. The product owner changed direction on this. The team agreed to defer that. Somebody raised a risk we had not thought about. Those are the things that shape the work, and they disappear faster than the code does.
I started keeping the whiteboard. Not the physical board. A photo of the board, cleaned up and dropped into my notes. I use a scanning app for this, not the regular camera on my phone. A phone camera treats a whiteboard like a landscape photo: it captures every glare, every shadow, every wrinkle in the paper. A scanning app treats it like a document. It fixes contrast, straightens edges, and gives me an image I can actually read later.
I started keeping screenshots and quick annotations. If I am looking at a UI bug and I need to send it to a teammate, I grab a screenshot, mark it up, and paste it into the note. Snagit does this well, but the specific app is not the point. The point is that an image with a circle and an arrow can replace a paragraph of description.
I started keeping the questions I did not want to interrupt to ask. Somebody is explaining a story and I have a question. Instead of breaking their flow, I type the question into my sprint note. Later, I clean it up and either ask it, add it to the story, or delete it if it answered itself. That small habit keeps meetings respectful and my memory honest.
From Data to Knowledge
The second shift was harder. I had to stop treating my notes like a data dump.
It is easy to collect things. Screenshots, transcripts, whiteboard photos, Slack snippets, calendar invites. After a few months you have a pile. But a pile is not knowledge. A pile is just a heap you search when you are desperate.
Knowledge requires distillation. I have to look at the raw material and ask what it means. What did we decide? Why? What changed? What should I remember? That is the work I am doing when I write the note. The tool does not do that for me.
This is why I do not worry much about which app I use. Over the last twenty years I have used Lotus Organizer, Schedule+, Microsoft Outlook, OneNote, Evernote, and now Obsidian. The tool changes. The practice stays. If I have the practice, I can move to a new tool. If I only have the tool, I am stuck when the tool changes or when I do not feel like opening it.
Decomposing My Own Work
There is a related trap I see in myself and in other developers. We are good at decomposing code. We refactor functions, split classes, untangle dependencies. We are much worse at decomposing our own tasks.
I have seen boards where a single story card sits in “Doing” for most of the sprint with one vague subtask: “Do it.” That is not decomposition. That is a placeholder for work nobody understands yet. I have caught myself doing the same thing in my own head: “I will just do this story.” No breakdown. No milestones. No clue where I am mid-week.
When I decompose my own work, I can see progress. I know where I am blocked. I can report something meaningful at stand-up. I can hand off context if I get pulled away. Decomposition is a planning exercise, but it is also a memory aid.
The Right Unit of Value
One more thing had to change. I had to stop measuring the sprint by how many cards I moved.
In a sprint review, nobody cares how many story points we completed. They care what value we delivered. The same is true for my own notes. I do not write down how many Pomodoro sessions I finished. I write down what I learned and how it might help us next time.
This is the same loop I use when building features with AI in the loop. The work produces artifacts, but what matters is the understanding they carry forward. I wrote about this a year into our AI experiment: tools matter only when they support a human system.
This Is Not a Best Practice
I want to be careful with one word: best. I do not think this is a best practice. It is a practice I am following right now. I revise it almost every quarter. I try a new template, a new tag, a new way of linking daily notes. Some changes stick. Some fail.
What does not change is the intent. I want my work to be visible to myself while I am doing it. I want to inspect it honestly. I want to adapt based on what I see. That is personal Scrum. The rest is implementation detail.
In the next post I will show the implementation detail that is working for me today: the note template I create in Obsidian at the start of every sprint.
The same values we sell to clients become a mirror when I point them at myself.
Leave a Reply