At the start of every sprint I create one note. I name it after the sprint number. The note starts mostly empty. It has a skeleton of sections and a few fields at the top. I fill it in as the days go by.
That note is the center of my personal Scrum. It is a container I build during the sprint, not a report I write at the end. By the time the sprint is over, the note has become a map of what happened and why.
The Top of the Note
I rely on a simple template. It drops in a few pieces of metadata automatically, and then it leaves the rest for me to complete.
The most important fields at the top are the main stories and a “worth noting” line. The main stories field is just a list of the work we committed to for the sprint. The worth noting field is more interesting. It is where I write a few one-liner memory triggers for the sprint: the sprint we went live, the sprint the new teammate joined, the sprint where a refactor made everything easier, the sprint where everything broke on Tuesday and we still shipped on Friday. Two months from now, when I look at a list of sprints, that single line is what lets me find the right one.
Below those fields, the note has a set of sections I use as anchors. The exact names shift depending on the project, but they follow the same rhythm: planning, modeling, refinement, daily work, review prep, review, retro, and lessons learned. Some sprints need extra sections. Most do not. The point is that every day has a place to land.
Here is what the skeleton looks like for a sprint I am calling Sprint 20:
# Sprint 20
**Main stories:**
- [link to story 1]
- [link to story 2]
## Planning
## Modeling
## Refinement
## Daily Log
## Sprint Review Prep
## Sprint Review
## Retro
## Lessons Learned
Planning
During sprint planning I sit in the same note the whole time. I do not try to capture the whole conversation. I capture the decisions, the questions, and the things I promised to follow up on.
If the product owner says we are deprioritizing a story, I write it down. If the team agrees to split a story a certain way, I write it down. If somebody asks me to look into a library or a tool, I write it down and tag the person who asked. That tag is for me, not for them. Later, when I see that name in another note, I can trace the request back to the original conversation.
I also keep a list of questions I do not want to interrupt the room to ask. When somebody is in the middle of explaining a story, I can type the question into my note, keep listening, and come back to it. Most of those questions either answer themselves or become useful additions to the story description. A few of them become the thing I ask in the next refinement session.
Modeling and Refinement
Most of the teams I work with run separate sessions for modeling and backlog refinement. Modeling is where we talk through the shape of the work. It might be a context-mapping session, a domain discussion, or a whiteboard conversation about where a new feature fits. I keep one section for that.
If we draw something on a whiteboard, I take a photo with a scanning app and drop it into the note. The photo is a decision artifact, not a souvenir. A month from now, when somebody asks why we split the accounts domain the way we did, I can point to the sketch and say, “This is what we were looking at when we made that call.”
Backlog refinement gets its own section too. This is where I note the stories we discussed, the estimates we agreed on, and the things we flagged for later. Sometimes I realize that the work we are doing this sprint will make next sprint’s story easier. I write that down and bring it up with the product owner. Those notes become the bridge between sprints.
The Daily Sections
At the bottom of the sprint note I keep a daily log. For each day of the sprint I add a heading with the date. That heading links to my daily note for that day, which I will describe in the next post. The link matters because it lets me jump from the sprint view to the day view and back.
Under each daily heading, I write what I worked on, what I learned, and where I got stuck. If I am pulled away from a story to something else, I write a “next” line before I switch. That breadcrumb is the single most useful thing in the whole system. It is what lets me pick the story back up without spending twenty minutes reconstructing where I was.
This is the part of the note that connects directly to The Daily Note as Navigation Hub I wrote about earlier. The sprint note gives me the arc of the sprint. The daily note gives me the texture of the day. Together they keep me oriented.
The Work-Item Level
Inside the daily sections, I keep a small entry for each story I touch. I paste a link to the story in our work tracking tool. Then I add my own notes: the contract we changed, the validation that broke, the pairing session where we figured out the right shape. If I hit a problem and solve it, I tag it lessons-learned. If I realize the team should see it, I note that I posted it to our internal knowledge base.
These entries are messy. They are written in the middle of work. They have typos and half-formed sentences. That is fine. This is not a polished report. The goal is to leave enough signal that future me can reconstruct the noise.
Review, Retro, and Lessons Learned
The last sections of the note start empty. I add to them as the sprint ends.
The sprint review prep section holds the main talking points, questions we may need to ask the stakeholders, and the demo script. The review section holds what we demonstrated and the feedback we collected. The retro section holds what went well, what did not, and the next actions we chose. The lessons learned section holds the things I want to bring to the team in our weekly learning session.
I do not wait until the last day to create these sections. They are in the template from day one. That way, whenever something review-worthy happens, I have a place to put it. The same is true for retro items. If a tool slowed me down on Wednesday, I write it in the retro section on Wednesday. By Friday I am not scrambling for cards.
The Template Is a Promise
I do not treat the template as a form to complete. I treat it as a promise to my future self. Each section is a prompt: did this happen? Is there something worth capturing here? If the section is empty at the end of the sprint, that is data too. It tells me the sprint did not include much modeling, or that the review did not produce feedback, or that I did not learn anything worth sharing.
That is hard to admit sometimes. But it is also useful. If my lessons-learned section is empty for three sprints in a row, I am either not growing or not paying attention. Either way, the empty section is telling me something.
In the next post I will zoom in on the daily note. That is where the breadcrumbs live. That is where I survive interruptions.
A good note template does not capture everything. It captures the right things in the right places.
Leave a Reply