Image from UnSplash
Preface Link to heading
This post describes how I’ve been conducting sprint planning on my current team. It deviates from standard agile in a few ways. I document how and why towards the bottom. I’ve found this format works well for us, but there is no process that works for everyone. I script out the sprint planning process to keep it focused and make sure we don’t forget to cover anything important.
Cycles tend to be between 1-3 weeks (depending upon team size, with a bias towards shorter cycles). Each sprint planning starts with a cloned template of our sprint planning document where we write ideas or topics.
Script begins below Link to heading
Each section happens in the order listed.
Socialize (5 minutes max) Link to heading
Each team member, in parallel, spends a few minutes writing down random social stuff. Maybe what they did last weekend, what video games they are playing, hobby stuff, etc. An example list may look like this:
* Jack
* Saw the latest marvel movie. It was cool
* Bowled
* John
* Chilled at home
* James
* Palworld!!!!!
If anything jumps out, we may talk about it “Oh I was playing Palworld too!”. The idea is to put all the social stuff out of the way, give people time to join, and get people more relaxed. This especially works since our meetings are on Monday mornings. Don’t spend too much time on this.
Notes from management sync Link to heading
I go over any notes from my manager or other managers that may impact the team. This could include new technology other teams are investigating or interesting blockers for their work we could potentially look at.
Thoughts from the last sprint Link to heading
Each team member, in parallel, writes their thoughts on how the last sprint went for them. It’s often helpful for each person to pull up their previous sprint in Linear as a reference. A random list of things people may point out are:
- Feels like we are in a groove. Got a lot done
- Spent a lot of untracked time answering Slack messages
- WAF project is taking much longer than we thought
- Mr. Bob is pinging me in DMs to help him a lot with X
- Feel a bit slow picking up framework Z
- Not feeling happy with how ticket Y keeps rolling over
An important goal here is not for me (the manager) to point out how others are failing. The goal is for people to feel open talking about what is or isn’t working about the sprint process. For example, people focus on their own sprint and not the progress of others. As a team, we try to brainstorm ways to make the next sprint better or find patterns across the team on things that are slowing us down.
Rather than keep things that are slowing you down in private in a 1:1 meeting, this allows other team members to hear what’s working and offer support or guidance.
Things to remember to work on Link to heading
This is a shared block of text that Notion keeps between sprint documents. It contains a bullet point list of small things we were trying to work on to improve our sprint process. For example, the list may look like
- Do better moving DMs to slack
- Write documentation for questions we get from developers
- Do high priority tickets before low priority ones
- Remember to make alerts if X fails again
The list is dynamic, usually short (2-3 items), and contains quick advice things we thought would be good to think about or work on to improve our sprint. It’s made directly from the “Thoughts from the last sprint” list last week.
If we successfully address a bullet point, we remove it. If not, we keep it (if still relevant). We also add bullet points according to things we thought blocked progress this sprint.
Check for short weeks, days off, PTO, on-call, company meetings, etc Link to heading
To keep top of mind, we check for/call out anything that would hinder our regular sprint cadence. These could be things like 4 day weeks, a company event, etc. We also call out who the squad on-call is, so we are prepared to keep that in mind when assigning work.
Review rolled-over work Link to heading
Linear automatically closes the last cycle Sunday night and has opened this one Monday morning: rolling over all the uncompleted work. We start with rolled over work, discussing if we still want to do it or if it’s still a priority. If things roll over too much, we may just backlog the ticket (things not getting done often indicates they may not be necessary) or cancel it. Later on, in private, I will try talking with team members about rolled over work if I feel there are performance issues at play: but I keep the conversations task focused in public.
Review commitments Link to heading
As a team that owns many projects, we often get requests from other developers to change or improve something. We try to communicate deadline expectations and then proactively place those tickets in the sprint they would get done in as “unassigned” work. We review these tickets and try to assign owners.
Review active major projects Link to heading
Our OKRs are major projects the team wants to complete. In Linear, these are project items in our current quarter (Q1/Q2/etc) that are in status “Active”. We iterate each active project and the project lead discusses what tickets need to be done and we divide work for their tickets.
When a project is completed, we close it and focus on other “active” projects until there is very little active work to do, in which case we then nominate a “backlog” project into “active” status. We try to keep the total number of active projects as small as possible.
Review total assigned sprint points Link to heading
We keep a rough number of the average sprint points completed per person per cycle and compare that to each person’s sprint total. If there is too much work, we’ll either repoint tickets (by narrowing scope) or unassign work. There’s no minimum number of points to hit per person, but we do have a max we try to stay under since I want to bias towards “under promise overdeliver” over “overpromise under deliver”.
Create company announcement of upcoming changes Link to heading
The goal here isn’t to brag about how much we do (which is what most “look at what we are doing” posts are), but instead to look for two primary things:
- Inform people of any infrastructure changes we are making that may impact them
- Announce new technologies we are investigating.
We post these in our public team Slack channel and a typical post may look like this:
:wave: Upcoming changes :wave:
* Starting PG14->PG15 upgrade on staging databases as scheduled *here*.
** We've reached out to all the teams that we are aware need to know. Please test any database APIs this and next week after the upgrade
* Restarting LBs in production to move to ARM instances. Expect temporary connectivity issues at X:00 PM.
** Follow along here for more information
* Investigating Kafka as a solution to the *previous* messaging issue we ran into
An important goal is to NOT list everything we are working on. Instead, list the things that may directly effect other employees. As another note, we find it useful to give a heads up on new tech we are researching to solve problems, in the hope that someone else at the company says “Hey I used Kafka at X inc and think you should do Y instead”.
Addendum: things not included in the planning process Link to heading
Backlog Link to heading
When work outnumbers people, the backlog is where tickets go to die. Tickets get out of the backlog when someone at the company is motivated for the ticket to complete. This honestly doesn’t have to be a lot of motivation: just the signal a ticket is important is often enough.
Otherwise, we review the backlog quarterly when planning major OKRs.
Living document Link to heading
Our sprint planning script is a living document. For example, one week we realized we over committed work because we forgot to think about a company all-hands event, so we added a section to check for short weeks.
No separate sprint retrospective Link to heading
Agile usually does a sprint retrospective as a separate meeting. Atlassian says these can take between 45 minutes - 3 hours. I’ve found the “thoughts from the last sprint” section captures the important parts of a retrospective and the advantage of not having yet another meeting in our short sprint cycle is worth it: all meetings, even “simple” ones, have a static switching cost.
No “Sprint review” Link to heading
A sprint review is “a time to showcase the work of the team”. Over time, these tend to focus on “Look how great we are” rather than the original iterative feedback loop. Instead, we send asynchronous messages about new features we want to test or get feedback on and make sure to notify interested parties.
No Sprint Goal Link to heading
Agile usually has a sprint goal. We don’t set or focus on one mostly because the breadth of work we do is so wide. I tend to agree with the reasons here particularly the point “Some teams simply have multiple things that need to get done”.
Ticket format Link to heading
The general format for sprint tickets is this:
Problem:
Action:
Acceptance criteria:
How detailed the ticket is reflects how complex it is to solve. Simple tickets can have simple text. For example:
Ticket title: Increase CLI test coverage
---
Problem: We broke the CLI last week for DB access
Action: Expand ./cli/db module test coverage
Acceptance criteria: Coverage for at least ./cli/db/Auth struct
It can be a genuine time sink creating the textbook perfect agile sprint task. It’s ok to take shortcuts to save time. Tickets need less details if:
- The developer …
- is more experienced
- has a track record of understanding what you want
- is familiar with the codebase or problem area
- is on your team or works closely with you
- consistently delivers
- The work …
- has a minor worse case scenario (unit tests, beta test tooling, etc)
- has no concrete deadline
- has many solutions, and you don’t care which is implemented
For completeness, tickets need more details on the converse:
- The developer …
- is less experienced
- tends to misunderstand work
- is unfamiliar with the codebase or problem area
- is on another team
- rolls over tasks frequently or is on a PIP
- The work …
- has a major worse case scenario (Database upgrades, security issues, etc)
- must get done this week
- has many solutions, but the team really wants one solution in particular
How do you run your sprint planning? Link to heading
I’d love to hear how you run your sprint planning. I’m always looking for ways to improve our process. Leave a comment below with your thoughts.