Design-Ops

Explore

Working Agile

Ceremony Cadence

There’s no one right way to run a sprint, but I’ve seen some work better than others and of course have thoughts and opinions...

⁠

Sprints: 2 or 3 Weeks?

The style of your sprint cadence comes down to what works best for your team size and working style.

Smaller, leaner teams will probably fit best with a longer sprint cycle to bake in the time to test and deploy their own code. Whereas, larger orgs with dedicated QA folks can make a 2 week cadence fly.

2 Weeks

⁠

Week 1 (Start)

Mon → Weekly Planning

Wed → Retrospective

Thu → Peer Reviews

Fri → Show-N-Tell / Team Fun

Week 2 (Close)

Mon → Weekly Planning

Wed → Backlog Refinement

Thu → Sprint Planning

Fri → Sprint Review

3 Weeks

⁠

Week 1 (Start)

Mon → Weekly Planning

Wed → Retrospective

Fri → Show-N-Tell / Team Fun

Week 2 (Working)

Mon → Weekly Planning

Wed → Backlog Refinement

Fri → Peer Reviews / Team Fun

Week 3 (Close)

Mon → Weekly Planning

Wed → Sprint Planning

Fri → Sprint Review

⁠

Meeting Structure & Timing

You’ll see a few calls repeated in the lists above, and titles like Planning, Retrospective, Refinement, and Review are probably familiar to anyone working today.

However, in my experience too much time is dedicated to the meetings themself each week and almost zero prep work is done ahead of time. Therefore, the call itself becomes a work session for the unprepared where the rest of attendees get frustrated and begin rating them low on health-checks and/or calling them a waste of time.

Meeting Length

Most studies about attention-span gravitates toward 45 minutes being the max-length for a productive call; which is probably why thinking back to 2 hour long planning sessions in poorly ventilated meeting rooms feel like war flashbacks to many of us.

So, here are some time recommendations that will force a bit of focus and preparation...

15 minutes

⁠

Daily Stand-up

Blockers Discussion (only as-needed)

Weekly 1-on-1’s

30 minutes

⁠

Weekly Planning

Sprint Review (w/ stakeholders)

Sprint Retrospective

1 hour

⁠

Backlog Refinement

Sprint Planning

Project Retrospective (run via moderator)

⁠

Async Saves The Day!

Looking at those times you might be asking how you can get anything done that quickly, and the key is simpler than it seems: having actual meeting agendas, which enables folks to come prepared for the call, and using asynchronous docs to capture things before, during, and after the call ends.

Slack or Teams can be part of this structure, but should NOT be the only or primary source of team, project, or status information / documentation.

Why, I hear you asking through my monitor? They are not organizable, have poor search capabilities, and seem to go-down more frequently than proper documentation tools (which can cache locally or even function offline). It’s also just not what they were built for. Misusing a tool can end up going as poorly for you as not having one with a simple update or change of terms/service.

Set yourself up for success, and look into these instead...

Cloud-based

Notion.so

Coda.io

Microsoft Loop

Hybrid / Both

Confluence

SharePoint

Nextcloud

Self-hosted

Obsidian.md

Logseq

Roam Research

⁠

Addendum & Corrections

An early version of this referred to “Backlog Refinement” as “Backlog Grooming” and I apologize for that initial oversight. While that term is still used in some orgs, the move away from language with negative connotations is beneficial to everyone and future-proofs the work we do today.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.