Scrum Master Series: Don’t leave sprint planning without…
From your friendly neighborhood Scrum Masters, this series is about processes we’ve tried, what we’ve learned, and where we’re headed. We’re committed to learning and growing, so if you read something today, there’s a chance we already iterated on it.
It’s taken our product development organization about 18 months to get to this point. We have product teams running scrum, collaborating on user stories, and delivering on a two week sprint cadence. Since I’ve been here, we’ve never been more collaborative across engineering, quality assurance, product management and design.
That being said, our meetings can be energetic and fast-paced, often up until the last minute of sprint planning. I’ve found success with a few different techniques to wrap up planning meetings, but often found it difficult to get them all in, or finish in time. So The Checklist was born. What was once in my head, is now located on the whiteboard beside our task board to prime the team of what we need to accomplish before we walk out of the room.
The Checklist
- A curated sprint backlog
- A curated task board
- A shared sprint goal
- An order of operations*
- An understanding of our capacities
- Filling excess capacity*
- Identifying user-facing items
- Identifying risky or dependent items*
- Identifying topics or demos we want to have this sprint
*Some of the points are self-explanatory or pretty traditional scrum techniques. Some of them are less so, and I’ll expand on those below.
An Order of Operations
We try to break our work down into small enough stories that we’re completing them within a sprint, but often things are still different sizes. We ran into a problem a few sprints ago where every engineer on my team picked up their largest and most difficult story right off the bat, which didn’t allow our other team members to optimize their time effectively. So now, at the end of sprint planning, each person walks through their work and in what order they plan on picking it up and handing it off.
By saying it out loud, we commit ourselves to the work and to our team mates. We get a broader sense that we’re one team and our work is affecting each other for the next two weeks. Second, it really puts into perspective our capacity and just how much work we’ve committed to completing.
Filling Excess Capacity
While we’ve successfully created cross-functional product teams to deliver products and features iteratively, we as individuals are mostly specialists at this point. Each functional team is represented, and we each do just that. We are working on the idea of becoming generalists, but until that time, we may hit bottlenecks on the amount of work we can pick up, leaving some excess capacity for certain individuals.
We’ve agreed the best way to fill that excess time is to allocate it towards learning and moving towards our shared goal of cross-functionality. So during this checklist item, we choose to add research, tech debt, or additional learning topics. This keeps our team focused and allows for some flexibility and team growth.
Identifying Risky or Dependent Items
While we don’t necessarily like to pick up cards that could be hiding unmitigated risks, or items that are dependent on another item, it happens. The best thing to do is to flag it and make sure I’m keeping an eye on it. This helps me track things, helps make the team more aware, and lowers the barrier of sounding the alarm if we’re getting off track.
