Engineering team
Methodology
Why two weeks
A one-week sprint doesn't leave room for blocked work to unblock. A four-week sprint accumulates so much surprise that the retro is overwhelming. Two weeks is the cadence at which we can plan, ship, demo, and retro before the next plan — and where surprises stay small enough to debug.
Not dogma — three-week sprints make sense when time zones force it. But two weeks is the default and we have to be argued into deviating.
What a demo looks like
A sprint demo is working software in production, shown to the customer's stakeholders, with an audience that includes at least one person who's allowed to say 'this isn't what I expected.'
It is not a screenshare of localhost. It is not a Figma walkthrough. It is not 'we're 80% done.' If we can't demo it in a deployed environment, we don't claim it shipped.
The retro template
Three columns, one workshop, one hour:
- What worked — the things we want to repeat next sprint.
- What surprised us — the gaps between what we expected and what happened.
- What we'll change next sprint — three or fewer concrete actions.
What we don't do
We don't keep a running 'parking lot' of unaddressed retro items. If something didn't make the top three, it doesn't get fixed this cycle. The list resets each sprint. This forces prioritization and prevents retro fatigue.