Scrum

Scrum is a way to manage a long term project, prioritizing regular assessment and course-correction over deep planning at the start of a project. It reminds me a bit of GTD in that it results in limiting your horizons, hyper-focusing on the short-term in terms of action, and then on the mid-term and long-term for planning; and it also shares similar processes.

Scrum prescribes for teams to break work into goals to be completed within time-boxed iterations, called sprints. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called daily scrums. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective. A person in charge of a scrum team is typically called a scrum master.

I'll start with a basic glossary, because it will make more sense:

Backlog: all tickets that are part of the project but have not been actioned yet. Usually added to throughout the project, with a big initial burst at the start of the project and smaller bursts at sprint kickoffs.
Sprint: a regular timeframe that a team works on their tasks, including lots of regular rituals.
Milestones: a checkpoint between the start and end of a project, usually with some rough estimate of a timeline to help stakeholders know what you are doing and when it will likely be done.
Stream: a team within a team, usually focused on a specific portion of the larger goal.
Sprint lead: the person owning the entire sprint's wrapup and kickoff process. This could rotate or stay the same (e.g. a manager). Their job is also to ensure everyone stays on track, timelines are met in meetings, etc.
User Stories: The way a problem is framed, usually as “As a [persona], I [want to], [so that].”[3]

Sprints and their rituals

Much of this was gleaned from teammates while I was at Atlassian. I think like any process, take what works and leave the rest.

Wrapup/Kickoff

Sprints are two weeks long, starting as early as possible in the week that includes all participants (this was a team spread across the world, so it was on Tuesday in Australia so Americans on Monday were there).

The first day of the sprint, there is a sprint wrapup for the previous one and a kickoff for the new one. This follows a general structure, which is outlined in a template that is copied and filled out by the team member who is leading the ritual (the "sprint lead").

Using a template

The template includes the following items as checklists, and general structures to facilitate them.

For planning the upcoming sprint, there are a few tables:

One for capacity considerations (if they are out of office, other projects, etc.), with a row for each person.
One for the actual work, with rows for each stream (team/goal within a team) and columns for goals, risks/blockers.
One for listing the risks and blockers noted above and mitigations to overcome them.

Before the sprint, the team lead does the following:

Sprint lead makes copy of template and follows checklists.
Groom the backlog
Estimate the backlog (has lots of weird canonical methods[2], but it's essentially just an abstract estimate of the size of a task within scope of the project and the sprint)
Add any team constraints (people out of office, other priorities coming up, etc.)
Copy information from previous sprint for the upcoming wrapup.

Wrapup

The wrapup is there as a regular "post-mortem" to ensure everything is going as expected, and fix any issues that may arise.

What did we say we'd do
What did we do
What went well
What didn't go well
Actions to take to avoid similar problems in the future

Kickoff

The kickoff is planning for the next sprint and what will be done.

What we are doing this sprint, answering these questions in the templated tables:
- For each person
  - Capacity considerations
- For each stream, what will be worked on this sprint
  - Upcoming milestones/goals
  - What was carried over from the previous sprint
  - What new tickets are being taken on and by who
  - Risks and blockers
- What relevant milestones exist outside your team
Completing the tactical/meta tasks before the sprint can begin:
- Discussing capacity constraints and upcoming events
- Closing the last sprint (usually only necessary if you are highly integrated in some Scrum system, like Jira)
- Discussing previously identified risks
- Picking a sprint name (an example of corporate "fun")

Post-Kickoff

The sprint lead does some meta/infra stuff.

Any final adjustments for tickets flagged during the ritual
Start the sprint (lots of this is infra-specific, e.g. Jira)
- Makes new board
- Writes out tickets for each new task from kickoff
- Make epic for each stream
- Tickets assigned to each person
- Refine estimates for each ticket to ensure it can get done

Standups

Standups are very short meetings that happen at the start of the work day. The idea is that if people feel like they need to sit down, it is taking too long. So each person gets a minute or two to briefly mention what they did yesterday, what they are planning today, and any blockers or questions. Discussions must not happen here, but outside the standup.

Mid-Sprint Check-in/Retro

The check-in is not necessary but useful to ensure again that everyone is on track. People in the team do a quick share of what is being worked on, around 2 minutes each. Sometimes discussions happen, but they should happen outside this meeting except in rare circumstances. Whole meeting takes around 20 minutes, ideally.

Immediately after the check-in is the retro. This is where we give time for each person to come up with reflections on their recent time, work, etc. Usually just three categories of "good", "bad", and "questions". This should include managers to ensure everyone gets the larger context and sentiment.

References

Incoming Links

Last modified: 202611081913